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 端口，测试写入和查询是否正常流转
不复杂但容易忽略：所有节点 time 同步、max_allowed_packet 一致、server_id 唯一、防火墙 放行组播 / 单播端口（如 33061）、MySQL 用户要有 CLONE_PLUGIN 权限（MGR 8.0.17+ 需要）。
