為什么不要依賴MySQL高可用性進行維護

本文小編為大家詳細介紹“為什么不要依賴MySQL高可用性進行維護”，內容詳細，步驟清晰，細節處理妥當，希望這篇“為什么不要依賴MySQL高可用性進行維護”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

1. 高可用性介紹

讓我們先來談談可用性。如果一個服務（如數據庫）在大多數時間內對用戶是不可用的，那么運行它就沒什么意義了。因此當我們談論可用性時，我們是指服務的可訪問程度。

對于任何正常運行的服務，人們有理由期待它總是在被需要時是可用的 - 但是也會有一些停機時間，一年中有一兩天，或者每月有幾個小時。

一個普遍的可用的服務對于許多用例場景來說可能是很好的，但是如果服務本質上是至關重要的，或者大量用戶依賴與一個服務，僅僅依靠「可用性」是不夠的。

這就是高可用性的意義所在。在最基本的條件下，高可用性確保比通常預期的水平更高的可用性，更具體的說，在允許維護、修補和一般錯誤以及故障的情況下，也能達到約定的水平。

2. 什么級別的可用性是高可用性？

對于什么是高可用性還沒有達成一致的定義，只是為了滿足特定的（更高的）可用性需求，它通常超過被護接受的「可用性」。事實上，你的組織可能會根據運營的需求來定義所需的可用性 - 權衡高可用性的成本與停機相關的損失的成本。

你需要的可用性水平可以通過百分比來表示。例如 99.99% 或者「4 個 9」的可用性意味著一年中最多有 52.06 分鐘的停機時間，而「6 個 9」或者 99.9999% 的可用性則限制一年有 31.56 分鐘的停機時間。

從本質上來說，選擇權在你手上 - 但是，同樣，這也是一種權衡。維持高可用性的成本將是昂貴的 - 需要額外的物理資源和軟件許可，并耗費你的人力資源。但是，你可能會發現這是一個值得付出的代價，為了避免中斷帶來的連鎖成本，或者因客戶不滿意而損失收入的風險。

3. 高可用性在實踐中是如何工作的？

你的高可用性基礎架構的確切性質取決于你的工作負載。然而，從廣義上來講，當有容錯性時，就可以實現高可用性，這樣即使一個服務或者設備出現故障，工作負載也不會中斷。通常情況下，這意為著沒有單點故障 - 所有服務和設備都在網絡和應用級別是完全冗余的。

根據服務的不同，這通常可能涉及到一些節點 - 例如，你的 MySQL 集群將多包含幾個節點，數據存儲在這上面。然后將多個節點和負載平衡工具結合，這樣如果一個節點失敗，請求將被引導發送到另一個節點。用戶仍然可以訪問可用的服務，即使性能稍微下降。

4. 在 MySQL 中配置高可用性

當然，你通往高可用 MySQL 數據庫的途徑將取決于你對 MySQL 的實現。概括的說，你需要創建具有多個節點的某種類型的 MySQL 集群 - 換句話說，你的數據必須是存儲在多個 MySQL 服務器上。

接下來，你需要一個可以在這些節點上復制數據的服務，確保每一個節點都有你的數據庫中包含的數據的精確備份。最后，你需要一個負載平衡器，確保任何數據庫請求被均勻地引導到數據庫節點 - 是的， 一個平衡負載 - 但是請確保即使有一個節點離線，請求也能得到滿足。

例如， MySQL 提供了一個面向高可用的商業產品 - Te MySQL InnoDB Cluster. 。它基于 MySQL 群組復制，這是確保 MySQL 數據庫環境中高可用性的一種流行的方式。

另一個替代的選擇是 Galera ，它多年來一直提供 MySQL 高可用性。如果你使用的是 MySQL 的 MariaDB 分支，你可以通過你用 Galera 集群運行多個節點來配置 MariaDB 環境的高可用性  - 同時依靠 HAProxy 進行負載平衡。另外，你也可以研究一下 MariaDB 自己的
MaxScale 產品。

5. 依賴高可用性好的理由…

企業規模的工作負載越來越多地使用高可用性原則，因為從長遠來看，它提供了最好的結果。下面是你應該考慮在你的操作中設置高可用性的幾個好的理由：

• 極其重要的應用. 一些應用根本無法承受任何停機時間，想一想軍事應用或者能源網絡。在這些情況下，高可用性是必須的，你沒有什么選擇，只能確保極高的可用性 - 盡管你可以做風險評估，并決定你到底需要多大的高可用性保證。

• 連鎖效應. 如果系統是一個工作負載的核心，即使短暫的停機也會導致廣泛的問題，因為連接和同步的系統將會連帶失敗。值得考慮在幾個核心的領域投入高可用性 - 如數據庫 - 因為考慮到可能很難恢復的更大連帶問題的成本，這可能是值得的。

• 收入損失. 高可用性，即使是數量不多的 9 ，也可以防止收入損失。對于一個主要的在線零售商來說，僅僅幾個小時的銷售損失，加上相關名譽損失，就會對底線產生非常重要的影響。

• 客戶的期望和服務水平協議. 你的業務操作可能會受到服務水平協議的約束，保證你的客戶端有一定的正常運行時間。如果是這種情況，你需要確保你的客戶端工作負載的服務具有正常運行時間的水平 - 你將通過高可用性來實現。如果做不到這一點會導致合同的終止，或者根據你的合同進行賠償懲罰。

這是高可用性的幾個好的有效理由 - 而且，這今天這個技術至上的世界里，有許多工作負載在沒有高可用性平臺的情況下根本無法運行。

6. … 和依賴高可用性錯誤的理由

不幸的是，高可用的日益盛行導致了它的濫用。因為高可用性使得系統變得異常健壯，技術團隊在執行系統管理任務的時候（如打補丁）可能會傾向走捷徑，因為那些團隊認為高可用性基礎設施將會簡單承擔一臺機器脫機的負擔。

實際上，它很快就會變得更加復雜。以 MySQL 集群為例。是的，如果你重啟一臺機器給它打補丁，由于高可用性，你的 MySQL 集群將繼續運行。但是，請記住，當你為了打補丁而關閉一個節點，然后重新啟動它時，會導致需要輸入的數據積壓。這個過程可能需要花費長時間才能完成。

不用說，每一臺數據庫主機都需要看到相同的數據。危險來自于重新同步的過程：如果在你已經關閉的一個節點并對其打補丁的情況下，另一個節點出現故障，這可能導致失去最終有效的法定人數。換句話說，保存關于數據「真相」的服務器數量可能低于可接受的水平。從這種狀態下恢復可能是困難和復雜的，甚至可能導致數據丟失。

7. 不要依賴高可用性進行維護#

高可用性是為了在出現故障時保證系統的正常運行。這種針對故障的固有保護并不是一個免費通行證，可以依賴高可用性的健壯，以不負責的方式執行的系統維護，并沒有人會注意到它。

相反，技術團隊應該依靠其他解決方案 - 例如，為正在打補丁的系統設置完全的冗余，而不是簡單地希望高可用性基礎設施能夠來抵擋壓力。或者，在可能的情況下，依靠實時打補丁的方式來替代，通過這樣的做來消除需要重啟服務來安裝補丁的效果。

盡管如此，依賴高可用性進行維護工作的顯示出令人擔憂的跡象。仔細觀察一下，你甚至會發現供應商的官方指導，指示用戶依靠高可用性來執行打補丁的任務，用戶只需希望在一個節點離線打補丁時，其他節點不要出現任何問題。

讀到這里，這篇“為什么不要依賴MySQL高可用性進行維護”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。