MySQL集群的核心目标是实现高可用、自动故障切换、读写分离和数据一致性；官方推荐MGR和InnoDB Cluster，其中InnoDB Cluster为集成MGR、Router与Shell的一体化轻量方案，需至少3节点且MySQL 8.0+；MHA适用于5.7等旧版本，依赖主从与手动配置；双主、纯中间件分片、无GTID主从及共享存储均属伪集群。
MySQL集群的核心目标不是“多台MySQL一起跑”
很多人一说集群，就想到买三台服务器装MySQL、主从复制配起来完事。其实真正的集群要解决的是高可用、故障自动切换、读写分离、数据一致性这几个关键问题。单纯主从复制只是基础，离“集群”还有距离。MySQL官方推荐的集群方案主要有两种：MySQL Group Replication（MGR）和MySQL InnoDB Cluster（基于MGR封装），它们比传统主从更接近“集群”的定义。
主流轻量级集群方案：InnoDB Cluster（推荐入门）
InnoDB Cluster 是 MySQL 官方整合了 MGR + MySQL Router + Shell 的一体化方案，对中小团队友好，部署相对清晰：
- 至少3个节点（奇数，避免脑裂），每个节点运行 MySQL 8.0+（必须启用 Group Replication 插件）
- 使用
mysqlsh（MySQL Shell）一键创建集群，自动配置复制通道、选举主节点、设置只读/读写角色 - 部署 MySQL Router 作为客户端访问入口，它会自动感知节点状态，把写请求发给主节点，读请求负载到从节点
- 当主节点宕机，集群在10–30秒内自动选出新主，Router 同步更新路由规则，应用几乎无感
传统但依然实用的高可用组合：MHA + 主从复制
如果还在用 MySQL 5.7 或对升级有顾虑，MHA（Master High Availability）仍是稳定选择：
- 依赖一主多从结构，MHA Manager 运行在独立监控节点，持续检测主库心跳
- 主库异常时，MHA 自动完成：从库日志补偿 → 提升最优从库为主 → 修改其他从库指向新主 → 更新 VIP 或 DNS
- 需手动配置 SSH 免密、GTID 开启、半同步复制（推荐），并定期演练 failover 流程
- 注意：MHA 不处理读写分离，需上层（如应用、Proxy）或配合 Atlas/MaxScale 实现
避坑提醒：哪些“伪集群”要谨慎
以下常见做法容易被误认为是集群，实际存在明显短板：
- 双主复制（Active-Active）：两个节点都可写，极易引发主键冲突、数据覆盖，除非业务严格分库分表且写逻辑隔离，否则不建议
- 仅靠中间件（如 MyCat、ShardingSphere）做分片：它们解决的是水平扩展问题，本身不提供高可用保障，后端 MySQL 单点故障仍会导致部分分片不可用
- 没开启 GTID + 没做延迟监控的主从：故障切换时无法准确判断从库数据位置，强行提升可能导致数据丢失
- 所有节点共用同一套磁盘（如 NAS）：看似冗余，实则单点存储故障会让整个集群瘫痪
起步建议：先跑通一个最小可用集群
别一上来就规划 6 节点跨机房。建议按这个顺序验证：
- 在同一台机器用不同端口启动 3 个 MySQL 实例（如 3307/3308/3309），配置好 MGR
- 用 mysqlsh 创建单主模式集群，确认状态为
ONLINE，插入数据验证同步 - 手动 kill 主节点进程，观察是否自动切换，并检查新主的 read_only 状态是否已关闭
- 启动 MySQL Router，用客户端连接 Router 端口，测试写入和查询是否正常流转
