此参考架构提供了一个概念框架，用于在 Google Distributed Cloud (GDC) 网闸隔离配置上部署和运行高可用性的客户自管 MySQL 8.4 数据库。它使企业客户和抢先体验客户能够使用强大的多可用区虚拟机 (VM) 设置可靠地维护关键数据库工作负载。
由于 GDC 网闸隔离配置不支持跨可用区 Kubernetes 延伸集群，因此该架构严格依赖于跨三个可用性网域部署的专用虚拟机，以确保持续运行并承受整个可用区故障，而不会丢失数据。
特性和功能
- 多可用区弹性：在三个不同的可用区中部署高弹性 3 节点配置，以防范单个基础设施可用区故障。
- 自动化高可用性和共识：使用组复制实现基于 Paxos 的共识集群，提供自动故障检测、节点协议和全局数据同步，而不会出现脑裂情况。
- 智能流量路由：共置的 MySQL 路由器实例负责管理连接路由。路由器会将写入操作（例如端口 6446）严格定向到活跃的主节点，并在同步的副本之间对读取操作（例如端口 6447）进行负载均衡。
- 全球负载均衡：与内置的 GDC 全球 L4 负载均衡器集成，为客户端应用提供单一、稳定的虚拟 IP (VIP)，从而抽象化底层节点拓扑。
架构原则
- 基于仲裁的共识：优先考虑严格的数据一致性。组复制强制执行基于 Paxos 的模型，该模型需要多数同意，从而消除了网络分区期间数据丢失或脑裂的风险。
- 关注点分离：将数据库引擎和共识层（组复制）与客户端流量路由层 (MySQL Router) 分离，同时使用 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 的解决方案参考实现