PDF (US Ltr) - 2.2Mb
PDF (A4) - 2.3Mb
目錄
MySQL InnoDB ClusterSet 透過將主要 InnoDB Cluster 與一個或多個位於其他位置（例如不同的資料中心）的複本連結，為 InnoDB Cluster 部署提供災害容錯能力。InnoDB ClusterSet 使用專用的 ClusterSet 複製通道，自動管理從主要叢集到複本叢集的複製。如果主要叢集由於資料中心遺失或失去與其的網路連線而無法使用，您可以改為啟用複本叢集，以還原服務的可用性。如需有關部署 InnoDB Cluster 的資訊，請參閱第 7 章，MySQL InnoDB Cluster。
InnoDB ClusterSet 部署中主要 InnoDB Cluster 和複本叢集之間的緊急故障轉移，可以由管理員透過 MySQL Shell (請參閱MySQL Shell 8.4.0) 使用 AdminAPI (請參閱第 6.1 節，「使用 MySQL AdminAPI」) 觸發，該功能包含在 MySQL Shell 中。您也可以在主要叢集仍然可用的情況下，執行從主要叢集到複本叢集的控制式切換，例如，如果需要在主要叢集上進行組態變更或維護。MySQL Router (請參閱MySQL Router 8.4) 會自動將用戶端應用程式路由到 InnoDB ClusterSet 部署中的正確叢集。
InnoDB ClusterSet 部署中的複本叢集在保持被動複本的狀態時，不會與主要叢集產生分歧，因為它不接受寫入。它可以由應用程式讀取，儘管應預期非同步複製的典型複製延遲，因此資料可能尚未完整。複本叢集的最小大小是單一成員伺服器執行個體，但建議至少使用三個成員以實現容錯。如果需要更多成員，例如因為複本叢集已透過切換或故障轉移成為主要叢集，您可以隨時使用 AdminAPI 透過 MySQL Shell 新增更多執行個體。InnoDB ClusterSet 部署中您可以擁有的複本叢集數量沒有定義的限制。
下圖中的範例 InnoDB ClusterSet 部署包含羅馬資料中心中的主要 InnoDB Cluster，以及里斯本和布魯塞爾資料中心的複本叢集。主要叢集及其複本叢集各由三個成員伺服器執行個體組成，一個主要伺服器和兩個次要伺服器。
非同步複製通道會將交易從主要叢集複製到複本叢集。名為 clusterset_replication 的 ClusterSet 複製通道會在 InnoDB 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 命令來執行此操作。您可以選擇修復無效的主要叢集並使其恢復連線，或者您可以捨棄原始的主要叢集，繼續使用新的主要叢集作為主要叢集，並建立新的複本叢集。