在企業環境中的停機成本迅速增加。在一項調查中，40% 的受訪者表示，僅僅一個小時的停機就使得他們的組織損失了 100 萬美金以上。確保資料庫服務持續可用顯然是值得的。
它為你的組織節省了大量資金，更不用說與各種形式和規模的利害關係人的關係。
那麼你如何確保持續可用性？持續可用性背後的概念稱為 高可用性 。在本文中，我們將概述什麼是高可用性以及如何為你的 MySQL 叢集實現高可用。
我們也指出高可用性的黑暗一面，即使系統管理員錯誤地依賴高可用性來執行維護任務 - 並解釋為什麼這麼做會破壞高可用性的目標，使你的企業運營面臨風險。
讓我們先來談談可用性。如果一個服務（如資料庫）在大多數時間內對使用者是不可用的，那麼運行它就沒什麼意義了。因此當我們談論可用性時，我們是指服務的可訪問程度。
對於任何正常運行的服務，人們有理由期待它總是在被需要時是可用的- 但是也會有一些停機時間，一年中有一兩天，或者每月有幾個小時。
一個普遍的可用的服務對於許多用例場景來說可能是很好的，但是如果服務本質上是至關重要的，或者大量用戶依賴與一個服務，僅僅依靠「可用性」是不夠的。
這就是高可用性的意義所在。在最基本的條件下，高可用性確保比通常預期的水平更高的可用性，更具體的說，在允許維護、修補和一般錯誤以及故障的情況下，也能達到約定的水平。
對於什麼是高可用性還沒有達成一致的定義，只是為了滿足特定的（更高的）可用性需求，它通常超過被護接受的「可用性」。事實上，你的組織可能會根據營運的需求來定義所需的可用性 - 權衡高可用性的成本與停機相關的損失的成本。
你需要的可用性等級可以用百分比來表示。例如 99.99% 或「4 個 9」的可用性意味著一年中最多有 52.06 分鐘的停機時間，而「6 個 9」或 99.9999% 的可用性則限制一年有 31.56 分鐘的停機時間。
從本質上來說，選擇權在你手上 - 但是，同樣，這也是一種權衡。維持高可用性的成本將是昂貴的 - 需要額外的實體資源和軟體許可，並耗費你的人力資源。但是，你可能會發現這是一個值得付出的代價，為了避免中斷帶來的連鎖成本，或是因客戶不滿意而損失收入的風險。
你的高可用性基礎架構的確切性質取決於你的工作負載。然而，從廣義上來講，當有容錯性時，就可以實現高可用性，這樣即使一個服務或設備出現故障，工作負載也不會中斷。通常情況下，這意為著沒有單點故障 - 所有服務和設備都在網路和應用層級是完全冗餘的。
根據服務的不同，這通常可能涉及一些節點 - 例如，你的 MySQL 叢集將多包含幾個節點，資料儲存在這上面。然後將多個節點和負載平衡工具結合，這樣如果一個節點失敗，請求將被引導發送到另一個節點。用戶仍然可以存取可用的服務，即使效能稍微下降。
當然，你通往高可用 MySQL 資料庫的途徑將取決於你對 MySQL 的實作。概括的說，你需要創建具有多個節點的某種類型的 MySQL 叢集 - 換句話說，你的資料必須是儲存在多個 MySQL 伺服器上。
接下來，你需要一個可以在這些節點上複製資料的服務，確保每個節點都有你的資料庫中包含的資料的精確備份。最後，你需要一個負載平衡器，確保任何資料庫請求被均勻地引導到資料庫節點 - 是的， 一個平衡負載 - 但是請確保即使有一個節點離線，請求也能得到滿足。
例如， MySQL 提供了一個高可用的商業產品 - Te MySQL InnoDB Cluster. 。它基於 MySQL 群組複製，這是確保 MySQL 資料庫環境中高可用性的一種流行的方式。
另一個替代的選擇是 Galera ，它多年來一直提供 MySQL 高可用性。如果你使用的是 MySQL 的 MariaDB 分支，你可以透過你用 Galera 叢集運行多個節點來配置 MariaDB 環境的高可用性 - 同時依靠 HAProxy 進行負載平衡。另外，你也可以研究一下 MariaDB 自己的
MaxScale 產品。
企業規模的工作負載越來越多地使用高可用性原則，因為從長遠來看，它提供了最好的結果。以下是你應該考慮在你的操作中設定高可用性的幾個好的理由：
這是高可用性的幾個好的有效理由 - 而且，這今天這個技術至上的世界裡，有許多工作負載在沒有高可用性平台的情況下根本無法運行。
不幸的是，高可用的日益盛行導致了它的濫用。因為高可用性使得系統變得異常健壯，技術團隊在執行系統管理任務的時候（如打補丁）可能會傾向走捷徑，因為那些團隊認為高可用性基礎設施將會簡單承擔一台機器脫機的負擔。
實際上，它很快就會變得更加複雜。以 MySQL 叢集為例。是的，如果你重啟一台機器給它打補丁，由於高可用性，你的 MySQL 叢集將繼續運作。但是，請記住，當你為了打補丁而關閉一個節點，然後重新啟動它時，會導致需要輸入的資料積壓。這個過程可能需要花費長時間才能完成。
不用說，每個資料庫主機都需要看到相同的資料。危險來自於重新同步的過程：如果在你已經關閉的一個節點並對其打補丁的情況下，另一個節點出現故障，這可能導致失去最終有效的法定人數。換句話說，保存關於資料「真相」的伺服器數量可能低於可接受的水平。從這種狀態下恢復可能是困難和複雜的，甚至可能導致資料遺失。
#高可用性是為了在故障時保證系統的正常運作。這種針對故障的固有保護並不是一個免費通行證，可以依賴高可用性的健壯，以不負責的方式執行的系統維護，並沒有人會注意到它。
相反，技術團隊應該依靠其他解決方案 - 例如，為正在打補丁的系統設置完全的冗餘，而不是簡單地希望高可用性基礎設施能夠來抵擋壓力。或者，在可能的情況下，依靠即時打補丁的方式來取代，透過這樣的做來消除需要重新啟動服務來安裝修補程式的效果。
儘管如此，依賴高可用性進行維護工作的顯示出令人擔憂的跡象。仔細觀察一下，你甚至會發現供應商的官方指導，指示用戶依靠高可用性來執行打補丁的任務，用戶只需希望在一個節點離線打補丁時，其他節點不要出現任何問題。
高可用性對於許多應用來說都至關重要 - 對於許多其他應用來說也是十分有益。配置正確， MySQL 資料庫可以提供幾乎完美的可用性，但這並不意味著技術團隊可以把可用性視為理所當然。
濫用高可用性架構來維護走捷徑是不可取的 - 風險比乍看之下更大。
相反，系統管理員應該尋找可以久經考驗的替代方案 - 包括冗餘和即時修補程式 - 來執行維護操作，而不傷害高可用性解決方案的能力。
原文網址：https://tuxcare.com/understanding-mysql-high-availability-good-and-bad-reasons-to-use-it/
譯文地址：https://learnku.com/mysql/t/71681
【相關推薦：mysql影片教學】
以上是聊聊為什麼不要依賴MySQL高可用性來維護的詳細內容。更多資訊請關注PHP中文網其他相關文章！
