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+ 需要）。
