Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

GDC 實體隔離方案的 MySQL 資料庫參考架構

本參考架構提供概念架構，說明如何在 Google Distributed Cloud (GDC) 實體隔離方案中，部署及操作高可用性的客戶代管 MySQL 8.4 資料庫。企業和搶先體驗客戶可透過強大的多可用區虛擬機器 (VM) 設定，可靠地維護重要資料庫工作負載。

由於 GDC 實體隔離方案不支援跨可用區 Kubernetes 延伸叢集，因此這個架構嚴格仰賴部署於三個可用性網域的專用 VM，確保作業不中斷，並在整個可用區故障時避免資料遺失。

多可用區韌性：在三個不同的可用區部署高韌性的 3 節點設定，防範單一基礎架構可用區故障。
自動化高可用性和共識：使用群組複製功能，建立以 Paxos 為基礎的共識叢集，提供自動故障偵測、節點協議和全域資料同步，避免腦裂情況。
智慧型流量轉送：共置的 MySQL Router 執行個體會管理連線轉送。路由器會將寫入作業 (例如通訊埠 6446) 嚴格導向至執行中的主要節點，並在同步副本之間平衡讀取作業 (例如通訊埠 6447) 的負載。
全域負載平衡：與內建的 GDC 全域 L4 負載平衡器整合，為用戶端應用程式提供單一穩定的虛擬 IP (VIP)，並抽象化基礎節點拓撲。

以法定人數為基礎的共識：優先考量嚴格的資料一致性。群組複製功能會強制執行 Paxos 模型，需要多數同意，因此可消除網路失聯期間資料遺失或腦裂的風險。
分離關注點：將資料庫引擎和共識層 (Group Replication) 與用戶端流量轉送層 (MySQL Router) 分離，同時使用 MySQL Shell 簡化叢集生命週期管理。
基礎架構最佳化：專為實體隔離環境設計，利用強大的 VM 繞過目前的 Kubernetes 網路限制。

架構

執行共置服務堆疊的三 VM 架構。

本節將詳細說明多可用區架構中的功能元件及其特定職責。

成效與一致性之間的取捨：由於群組複製會強制執行共識，因此交易需要叢集對等點的確認。效能與 GDC 環境中的可用區間網路延遲時間直接相關。
資源管理：直接在資料庫 VM 上部署 MySQL Router，可最佳化硬體使用率，但需要仔細調整資源，以免連線集區負擔過重，導致核心 MySQL 程序資源不足。

Kubernetes 上的虛擬機器：GDC 實體隔離方案不支援跨多個實體可用區的 Kubernetes 叢集。之所以嚴格選擇以 VM 為基礎的方法，是因為在不同可用區部署專用 VM，是實現真正的多可用區高可用性，並在整個可用區故障時存活的唯一可行方法。
InnoDB 叢集與 Orchestrator 和 ProxySQL 的比較：我們評估了傳統的主要/次要架構搭配 ProxySQL 和 Orchestrator 的可行性。不過，我們最終選擇內建的 InnoDB Cluster (Group Replication + MySQL Router + MySQL Shell)，因為這項服務可消除對第三方轉送疊加層的依賴，並直接在 MySQL 內保持共識，大幅簡化容錯移轉的作業複雜度。
平台內建全域負載平衡：運用內建的 GDC 全域 L4 負載平衡器，確保 VIP 由 GDC 控制層控管，維持進入點的彈性，並簡化跨可用區流量傳遞。