這項參考架構提供概念架構，協助您在 Google Distributed Cloud (GDC) 實體隔離環境中，部署及運作高可用性、客戶管理的 MySQL 8.4 資料庫。企業和搶先體驗客戶可透過這個功能，使用穩健的多區域虛擬機器 (VM) 設定，可靠地維護重要資料庫工作負載。
由於 GDC air-gapped 不支援跨區域 Kubernetes 延展叢集，因此這個架構嚴格依賴部署在三個可用性網域的專屬 VM，確保作業持續進行，並在整個區域發生故障時不會遺失資料。
特點與功能
- 多可用區復原能力：在三個不同的可用區部署高復原力的 3 節點設定，防範單一基礎架構可用區故障。
- 自動化高可用性和共識：使用 Group Replication 進行以 Paxos 為基礎的共識叢集，提供自動故障偵測、節點協議和全域資料同步，不會發生腦裂情況。
- 智慧型流量轉送：位於同一位置的 MySQL Router 執行個體會管理連線轉送。路由器會將寫入作業 (例如通訊埠 6446) 嚴格導向至主要節點，並在同步複本之間進行讀取作業的負載平衡 (例如通訊埠 6447)。
- 全域負載平衡：與內建的 GDC 全域 L4 負載平衡器整合，為用戶端應用程式提供單一穩定的虛擬 IP (VIP)，並抽象化底層節點拓撲。
架構原則
- 以仲裁為準的共識：優先考量嚴格的資料一致性。群組複寫會強制執行以 Paxos 為基礎的模型，需要多數同意，因此可消除網路分割期間的資料遺失或腦裂風險。
- 關注點分離：將資料庫引擎和共識層 (Group Replication) 與用戶端流量路徑層 (MySQL Router) 分離，同時使用 MySQL Shell 簡化叢集生命週期管理。
- 基礎架構最佳化：專為無網路連線環境設計，利用強大的 VM 繞過目前的 Kubernetes 網路限制。
架構
概念與技術
本節將詳細說明多區域架構中的功能元件，以及這些元件的具體責任。
基礎架構和平台
- 虛擬機器 (VM)：三個專屬的 Compute 執行個體，每個執行個體都部署到不同的可用區，形成故障網域邊界。
- GDC 全球 L4 負載平衡器：平台管理的網路建構體，可公開穩定的內部 VIP，並自動評估 MySQL 路由器健康狀態檢查，以重新導向連入流量。
服務和邏輯
- MySQL 8.4：核心關聯式資料庫引擎。
- 群組複製 / InnoDB Cluster：內建叢集架構，負責多主機複製作業，並使用 Paxos 驗證節點仲裁。
- MySQL Shell：專用的統一指令列介面，用於設定、佈建及管理 InnoDB 叢集執行個體。
- MySQL Router：在每個 VM 上充當流量路由器。動態設定為監聽叢集中繼資料並轉送流量：寫入作業使用主動/備份，讀取作業則使用循環配置。
資料流程和介面
- 應用程式會將資料庫要求傳送至 GDC 全域 L4 負載平衡器 VIP。
- 負載平衡器會將連線代理至其中一個 VM 上健康狀態良好的 MySQL 路由器執行個體。
- MySQL Router 會根據要求的通訊埠動態轉送流量：通訊埠 6446 會嚴格將寫入作業導向運作中的節點，而通訊埠 6447 則會在叢集中循環讀取。
注意事項
- 效能與一致性之間的取捨：由於群組複製功能會強制執行共識，交易需要叢集對等互連的確認。效能與 GDC 環境中的區域間網路延遲直接相關。
- 資源管理：直接在資料庫 VM 上部署 MySQL Router 可提高硬體使用率，但需要仔細調整資源，以免連線集區的負擔耗盡核心 MySQL 程序資源。
設計決策
- 透過 Kubernetes 執行的虛擬機器：GDC Air-gapped 不支援跨多個實體區域的 Kubernetes 叢集。我們嚴格選擇以 VM 為基礎的方法，是因為在不同可用區部署專屬 VM，是唯一能實現真正多可用區高可用性，並在可用區全面故障時存活的方法。
- InnoDB Cluster 與 Orchestrator 和 ProxySQL：傳統的主/次要架構搭配 ProxySQL 和 Orchestrator，經評估後可做為可行的替代方案。不過，我們選擇了內建的 InnoDB Cluster (Group Replication + MySQL Router + MySQL Shell)，因為這樣就不必依賴第三方路由疊加，而且共識直接保留在 MySQL 中，可大幅簡化容錯移轉的作業複雜度。
- 平台內建的全球負載平衡：善用內建的 GDC 全球 L4 負載平衡器，確保 VIP 由 GDC 控制層控管，維持進入點的復原能力，並簡化跨區域流量傳輸。
假設和限制
假設
- 基礎架構可用性：客戶有充足的專案配額，可佈建專屬的適當大小 VM，以及平均分布在三個可用區的全球負載平衡器。
- 安全網路：建立以金鑰為基礎的存取權和適當的 ProjectNetworkPolicy (PNP)，允許叢集內 Group Replication 同步處理和 MySQL Router 流量。
限制
- 不支援 Kubernetes：如果客戶嚴格要求以容器化/Kubernetes 為基礎的解決方案，則平台完全支援延展叢集前，客戶無法實現多區域 HA。
- 需要手動升級：與代管服務不同，這個解決方案會將例行 OS 層級修補和資料庫次要版本升級的責任完全交給客戶。
- 網路延遲敏感度：複製作業需要高品質的穩定網路。如果無網路連線區域之間的網路抖動或延遲時間突然增加，MySQL 叢集中的寫入作業就會相應延遲。
其他教材
- 解決方案參考實作 (SRI)： Solution Reference Implementation for Highly-Available, Multi-Zone MySQL 8 in GDC air-gapped