此参考架构提供了一个概念框架，用于在 Google Distributed Cloud (GDC) 网闸隔离配置中部署和运行高可用性、客户管理的 MySQL 8.4 数据库。借助这种设置，企业客户和抢先体验客户可以利用强大的多可用区虚拟机 (VM) 设置，可靠地维护关键数据库工作负载。
由于 GDC air-gapped 不支持跨可用区 Kubernetes 伸缩集群，因此该架构严格依赖于部署在三个可用性网域中的专用虚拟机，以确保持续运行并承受整个可用区故障而不会丢失数据。
特性和功能
- 多可用区弹性：一种高弹性的 3 节点配置，部署在三个不同的可用区中，可防范单个基础设施可用区故障。
- 自动实现高可用性和共识：使用基于 Paxos 的共识集群 Group Replication，可自动检测故障、达成节点一致性并实现全局数据同步，而不会出现脑裂情况。
- 智能流量路由：共置的 MySQL Router 实例管理连接路由。路由器将写入操作（例如，端口 6446）严格定向到活动主节点，并将读取操作（例如，端口 6447）在同步副本之间进行负载均衡。
- 全球负载均衡：与内置的 GDC 全球 L4 负载平衡器集成，为客户端应用提供单个稳定的虚拟 IP (VIP)，从而抽象化底层节点拓扑。
架构原则
- 基于法定人数的共识：优先考虑严格的数据一致性。组复制采用基于 Paxos 的模型，要求达成多数一致，从而消除了网络分区期间的数据丢失或脑裂风险。
- 关注点分离: 将数据库引擎和共识层（组复制）与客户端流量路由层（MySQL 路由器）解耦，同时使用 MySQL Shell 简化集群生命周期管理。
- 基础架构优化：专为气隙环境设计，利用强大的虚拟机来绕过当前的 Kubernetes 网络限制。
架构
概念和技术
本部分详细介绍了多可用区架构中的功能组件及其具体职责。
基础架构和平台
- 虚拟机 (VM): 三个专用计算实例，每个实例都部署在单独的可用区中，以形成故障域边界。
- GDC 全球 L4 负载平衡器: 一个平台管理的网络结构，公开一个稳定的内部 VIP，自动评估 MySQL 路由器健康检查以重定向入站流量。
服务和逻辑
- MySQL 8.4: 核心关系型数据库引擎。
- 组复制 / InnoDB 集群：内置的集群框架，负责使用 Paxos 进行多主复制和验证节点仲裁。
- MySQL Shell: 统一的命令行界面，专门用于配置、部署和管理 InnoDB 集群实例。
- MySQL 路由器：充当每个虚拟机上的流量路由器。动态配置为监听集群元数据并转发流量：写入时采用主动/备份模式，读取时采用轮询模式。
数据传输和接口
- 应用将数据库请求发送到 GDC 全球 L4 负载平衡器 VIP。
- 负载平衡器会将连接代理到其中一个虚拟机上的运行状况良好的 MySQL Router 实例。
- MySQL 路由器会根据所请求的端口动态转发流量：端口 6446 严格针对活动节点进行写入，而端口 6447 则在整个集群中循环读取。
注意事项
- 性能与一致性之间的权衡：由于组复制会强制执行共识，因此事务需要集群对等方的确认。性能与 GDC 环境中的区域间网络延迟直接相关。
- 资源管理: 直接在数据库虚拟机上部署 MySQL Router 可以优化硬件利用率，但需要仔细调整资源，以防止连接池开销导致核心 MySQL 进程资源不足。
设计决策
- Kubernetes 上的虚拟机：GDC 网闸隔离配置 不支持跨多个物理区域的 Kubernetes 集群。之所以严格选择基于虚拟机的方案，是因为在不同的区域中部署专用虚拟机是实现真正的多区域高可用性并在整个区域发生故障时也能正常运行的唯一可行方法。
- InnoDB 集群与 Orchestrator 和 ProxySQL：我们评估了与 ProxySQL 和 Orchestrator 配对的传统主/从架构，认为它是一种可行的替代方案。不过，我们最终选择了内置的 InnoDB 集群（组复制 + MySQL Router + MySQL Shell），因为它无需依赖第三方路由叠加层，并通过将共识直接保留在 MySQL 中，大幅简化了故障切换方面的运营复杂性。
- 平台内置的全球负载均衡：利用内置的 GDC 全球 L4 负载均衡器，确保 VIP 由 GDC 控制平面控制，从而保持入口点的弹性并简化跨区域流量传送。
假设和限制
前提
- 基础架构的可用性：客户有足够的项目配额来预配专用且大小合适的虚拟机和全球负载平衡器，这些资源均匀分布在三个可用区中。
- 安全网络：已建立基于密钥的访问权限和适当的 ProjectNetworkPolicies (PNP)，以允许集群内组复制同步和 MySQL Router 流量。
限制
- 不支持 Kubernetes：如果客户严格寻求基于容器/Kubernetes 的解决方案，则在平台完全支持跨区域集群之前，无法实现多区域高可用性。
- 需要手动升级：与托管式服务不同，此解决方案将例行操作系统级修补和数据库次要版本升级的责任完全交给客户。
- 对网络延迟的敏感度：复制需要高质量的稳定网络。气隙区域之间的网络抖动或延迟峰值会按比例延迟 MySQL 集群中的写入操作。
其他资料
- 解决方案参考实现 (SRI)： GDC 网闸隔离配置环境中高度可用的多区域 MySQL 8 的解决方案参考实现