什麼是 MySQL 高可用性？

MySQL 高可用性是一個選項，您可以選擇讓 MySQL 資料庫在發生故障或中斷時保持可用狀態。此功能可讓您設定更高的運作時間需求，以及零資料遺失公差。在本文章中，我們將探討高可用性的一般概念，以及 MySQL 的高可用性選項如何運作。 

什麼是高可用性？

高可用性是指系統或服務在發生故障或中斷時能夠繼續運作並保持可用。高可用性系統可確保組織的任務關鍵系統與應用程式永遠運作。對醫療、金融和航空等領域的組織而言，這尤其重要，因為任務關鍵系統的故障可能造成嚴重後果。

高可用性通常以服務等級協議（SLA）定義的正常運行時間百分比表示，分數為 100，表示系統永遠不會故障。由於幾乎無法達成，大多數組織都以「五成」或 99.999% 的可用性為目標。

MySQL 如何實現高可用性

如果發生故障，高可用性系統必須能夠立即復原。高可用性架構至少需要三個基本要素，才能共同確保可復原性與高可用性：

故障偵測

MySQL 具有高可用性選項，使應用程式能夠滿足更高的運行時間（以及零資料丟失容差）。當高可用性選項開啟時，MySQL 系統會在不同的故障網域或可用性區域建立三個實例。

使用 MySQL Group Replication 將資料複寫到三個實例中，應用程式會連接到主要實例，以便讀取和寫入資料庫的資料。若發生故障，系統會在幾分鐘內自動將故障切換到次要實例。

容錯移轉

容錯移轉機制會將服務傳輸到複寫的執行個體。如果有多個備份執行個體可用，容錯移轉機制會選擇最適合的備份執行個體，以推廣至主要節點。 

重新導向機制

一旦容錯移轉到次要執行個體，高可用性功能會將所有應用程式和使用者連線重新導向至現在新的主要節點。它也會將所有查詢從舊的主節點重新導向至新的主資料庫。 

MySQL 高可用性：運作時間

運作時間是指系統可用且正常運作的時間，以系統預期運作的總時間百分比表示。高運作時間意味著系統多數時間都能如預期運作。 

MySQL 高可用性的不同層級，可預期的運作時間取決於您實作的特定高可用性（HA）解決方案。

MySQL Replication

MySQL Replication 可讓您設定多台伺服器，以提供備援和故障轉移，以支援比無 HA 功能的 MySQL 伺服器更高的運作時間。主從式組態使用單一主伺服器，可接受讀取與寫入，以及一個或多個唯讀從屬伺服器。主伺服器的資料會非同步複寫至從屬伺服器。

若要實作容錯移轉，您需要將一個或多個從屬伺服器設定為備用伺服器，以便在發生故障時升級為主要伺服器。容錯移轉通常是手動流程，您必須將升級的從屬節點狀態變更為讀寫模式，才能接受查詢，才能將從屬節點升級為主要節點。

因為故障轉移是手動進行的，所以需要更長的時間，而且可能容易發生人為錯誤，導致更長的斷電時間。MySQL Replication 也使用非同步複寫，這表示如果主機發生故障，主機上的交易可能尚未複寫到從屬伺服器。如果有重大資料遺失，將需要還原資料，並增加系統停機的時間。

MySQL Group Replication

MySQL Group Replication 可讓您達到比 MySQL Replication 更高的運作時間。使用 MySQL Group Replication，您可以在群組中設定多個 MySQL 伺服器，其中一台伺服器指定為主要伺服器，另一台伺服器則指定為次要伺服器。群組中的每台伺服器都會維護一份資料副本，並使用複寫來確保副本保持同步。 

如果主要伺服器故障，群組中的次要伺服器會自動偵測故障，並開始容錯移轉程序。其中一個次要伺服器會自動升級為新的主要伺服器，並開始服務來自用戶端的要求。群組中的其他次要成員現在會從新的主要伺服器收到更新，並繼續處理用戶端讀取要求。

如果故障的伺服器恢復連線，它會自動將群組重新加入為次要伺服器。

由於 MySQL Group Replication 功能會自動發生故障偵測和故障轉移，因此停機時間極小，使用者和應用程式通常都不知道發生了故障。 

MySQL Cluster

MySQL Cluster HA 解決方案提供最高等級的運行時間。這個高可用性的分散式資料庫系統，以及自動故障轉移和負載平衡，可提供高水準的可用性、效能和可擴充性，旨在提供接近零的停機時間。 

MySQL Cluster 使用三種類型的節點，共同儲存和管理資料：

• 資料節點：儲存資料並處理讀寫查詢。
• MySQL 伺服器節點：從用戶端應用程式接收查詢，在資料節點上處理查詢，然後將結果傳回給用戶端。
• 管理節點：管理叢集的運作，並在故障發生時處理故障轉移和復原。

如果叢集中的一個或多個節點故障，則叢集會自動偵測問題並觸發容錯移轉程序。整個流程通常在故障發生後的一秒內完成，不會中斷用戶端應用程式的服務。叢集持續正常運作，幾乎沒有停機時間。

MySQL 高可用性：復原時間 

復原時間是測量 MySQL 系統從中斷中復原所需的時間。較長的復原時間會導致可用性降低，並直接影響企業創造營收、員工生產力和客戶滿意度的能力。

在 MySQL 中，復原時間會因您使用的複寫類型而異：

• 主從式複寫的 MySQL 複寫復原時間將受手動容錯移轉流程的影響。將從屬伺服器升級為新的主要節點後，您必須重新啟動，才能開始將資料複製到剩餘的從屬伺服器。然後，您需要考慮遺漏的交易，並解決可能發生的任何衝突。
• Group Replication 使用自動故障偵測與故障轉移流程，比主從式複寫能縮短復原時間。衝突偵測與解決機制可確保每台伺服器上的資料，在群組內所有伺服器上皆永遠保持同步。群組複寫也使用無衝突複寫資料類型（CRDT），在發生衝突時自動核對資料。有了群組複寫功能，系統就能從故障中復原，而且停機時間非常少。
• MySQL Cluster 使用“什麼都不用共用”方法，其中叢集中的每個節點都被分配自己的記憶體和磁碟儲存，並使用高速連接與其他節點通訊。即使一個或多個節點故障，MySQL Cluster 仍能繼續運作。叢集會自動偵測問題，並觸發故障轉移過程，在幾乎沒有停機時間的情況下復原。

如何判斷您的 MySQL HA 需求

若要判斷您的 MySQL 高可用性需求，您需要考量幾個因素，包括：

• 您目前的系統架構：您目前的系統包含哪些元件，以及如何配置這些元件？ 他們能支援 MySQL 高可用性嗎？
• 預算：您需要為硬體、軟體和人員等資源投入多少資金？ 此外，考慮與訓練和持續維護相關的成本。
• 業務需求：考慮您的恢復時間目標（RTO）和恢復點目標（RPO）。您理想的復原時間為何？ 您需要多快從故障中復原？ 考慮您的組織是否受到任何特定監管或合規要求的約束，這些要求需要高可用性。
• 資料關鍵性：您的業務資料有多重要？ 保持最新狀態有多重要？ 您可以承受多少資料遺失？

何時使用 MySQL 高可用性

讓我們考慮幾個需要 MySQL 高可用性解決方案的使用案例：

高流量網站

高流量網站每秒處理上千筆查詢和交易，更不用說有上千名同時使用者。伺服器備援和負載平衡等高可用性措施可確保資料庫維持可用狀態，並可處理負載。 

即使伺服器故障，備援伺服器也能確保網站維持可用狀態，同時跨多台伺服器的負載平衡傳入請求，將防止單一伺服器超載並離線。

任務關鍵型應用程式和工作負載

具有任務關鍵系統和應用程式的企業需要高度的可用性和正常運行時間。大多數時候，這些系統無法承受任何停機時間，資料庫必須隨時保持可用。 

MySQL HA 解決方案，如群組複寫或叢集，是這種使用案例的理想選擇，因為它們採用自動故障轉移機制，幾乎不會停機。

Pure Storage 如何支援 MySQL 高可用性

Pure Storage® Evergreen 是一套提供 零停機時間部署的訂閱方案。Evergreen 結合 Pure Storage 獨特的儲存陣列架構，可讓您升級儲存基礎架構，同時不中斷服務工作負載。 

Pure 還支援 雙主動叢集 ，以及自動、透明的故障轉移功能， Purity ActiveCluster 是多據點雙主動延伸叢集，可實現零 RPO 和 RTO。

此外，也可考慮  Pure Cloud Block Store 的營運，為任務關鍵型應用程式提供企業級雲端可靠性。跨可用性區域的升級不中斷，高可用性實現了多雲業務永續性和災害復原的高可用性。