第 8 章 MySQL InnoDB ClusterSet

MySQL InnoDB ClusterSet 透過將主要 InnoDB Cluster 與一個或多個位於替代位置 (例如不同的資料中心) 的複本連結，為 InnoDB Cluster 部署提供災害容錯。InnoDB ClusterSet 使用專用的 ClusterSet 複寫通道，自動管理從主要叢集到複本叢集的複寫。如果主要叢集因資料中心遺失或與其網路連線中斷而無法使用，您可以改為啟用複本叢集，以還原服務的可用性。如需部署 InnoDB Cluster 的相關資訊，請參閱第 7 章，MySQL InnoDB Cluster。

InnoDB ClusterSet 部署中主要 InnoDB Cluster 與複本叢集之間的緊急容錯移轉，可由管理員透過 MySQL Shell (請參閱MySQL Shell 9.0.0) 使用 AdminAPI (請參閱第 6.1 節，「使用 MySQL AdminAPI」) 觸發，AdminAPI 包含在 MySQL Shell 中。您也可以在主要叢集仍然可用的情況下，執行從主要叢集到複本叢集的受控切換，例如，如果主要叢集需要組態變更或維護。MySQL Router (請參閱MySQL Router 9.0) 會自動將用戶端應用程式路由至 InnoDB ClusterSet 部署中的正確叢集。

InnoDB ClusterSet 部署中的複本叢集在保持被動複本時，無法偏離主要叢集，因為它不接受寫入。它可由應用程式讀取，但應預期非同步複寫的典型複寫延遲量，因此資料可能尚未完整。複本叢集的最小大小為單一成員伺服器執行個體，但建議至少三個成員以獲得容錯能力。如果需要更多成員，例如因為複本叢集已透過切換或容錯移轉成為主要叢集，您可以隨時透過使用 AdminAPI 的 MySQL Shell 新增更多執行個體。您在 InnoDB ClusterSet 部署中可以擁有的複本叢集數量沒有定義限制。

下圖中的範例 InnoDB ClusterSet 部署包含羅馬資料中心中的主要 InnoDB Cluster，以及里斯本和布魯塞爾資料中心中的複本叢集。主要叢集及其複本叢集各包含三個成員伺服器執行個體，一個主要和兩個次要。

圖 8.1 InnoDB ClusterSet 概觀

非同步複寫通道會將交易從主要叢集複寫到複本叢集。在 InnoDB ClusterSet 建立過程中，會在每個叢集上設定名為 clusterset_replication 的 ClusterSet 複寫通道，當叢集為複本時，它會使用該通道從主要複寫交易。基礎的群組複寫技術會管理通道，並確保在主要叢集的主要伺服器 (作為傳送者) 與複本叢集的主要伺服器 (作為接收者) 之間始終進行複寫。如果為主要叢集或複本叢集選出新的主要伺服器，則會在它們之間自動重新建立 ClusterSet 複寫通道。

雖然範例 InnoDB ClusterSet 部署中的每個叢集都有一個主要的 MySQL 伺服器，但只有主要 InnoDB Cluster 的主要伺服器接受來自用戶端應用程式的寫入流量。複本叢集不接受。MySQL Router 執行個體會將所有寫入流量路由至羅馬資料中心中的主要叢集，由主要伺服器處理。大多數讀取流量也會路由至主要叢集，但僅發出讀取請求的報表應用程式會改為路由至其本機資料中心的複本叢集，以節省網路資源。請注意，處理讀取和寫入流量的 MySQL Router 執行個體會設定為將流量路由至 InnoDB ClusterSet 中的主要 InnoDB Cluster，無論它是哪一個。因此，如果其他叢集之一在受控切換或緊急容錯移轉後成為主要叢集，則這些 MySQL Router 執行個體會改為將流量路由至該叢集。

務必了解，InnoDB ClusterSet 會將可用性優先於資料一致性，以最大化災害容錯能力。每個個別 InnoDB Cluster 內的資料一致性由基礎的群組複寫技術保證。但是，正常的複寫延遲或網路分割可能會導致部分或所有複本叢集在主要叢集發生問題時，與主要叢集不完全一致。在這些情況下，如果您觸發緊急容錯移轉，任何未複寫或分歧的交易都有遺失的風險，並且只能手動復原和協調 (如果它們可以被存取)。無法保證在緊急容錯移轉時會保留資料。

因此，您應始終嘗試在觸發緊急容錯移轉之前，修復或重新連線主要叢集。AdminAPI 消除了直接使用群組複寫來修復 InnoDB Cluster 的需求。如果無法快速修復或無法連線到主要叢集，您可以繼續將緊急容錯移轉至複本 InnoDB Cluster，以還原應用程式的可用性。在受控切換過程中，會確保資料一致性，而原始主要叢集會降級為運作中的唯讀複本叢集。但是，在緊急容錯移轉過程中，無法確保資料一致性，因此為了安全起見，在容錯移轉過程中會將原始主要叢集標記為無效。如果原始主要叢集保持在線上，應在可以連線時盡快將其關閉。

如果沒有問題且交易集與拓撲中的其他叢集一致，您可以稍後將無效的主要叢集重新加入 InnoDB ClusterSet 拓撲。檢查、還原和重新加入無效的主要叢集不會自動發生，管理員需要使用 AdminAPI 命令來執行此操作。您可以選擇修復無效的主要叢集並將其重新上線，也可以捨棄原始主要叢集，繼續將新的主要叢集作為主要叢集使用，並建立新的複本叢集。