MySQL集群包含主从复制、MGR、InnoDB Cluster及第三方中间件四类方案：主从复制成熟简单但有延迟；MGR基于Paxos提供强一致性和自动故障转移；InnoDB Cluster是MGR的封装版，开箱即用；中间件方案适用于超大规模分片场景。
MySQL 集群不是单一产品，而是多种高可用、高性能架构模式的统称。选择哪种方式，取决于你的核心需求：是追求强一致性（如金融类事务）、读写分离扩展、自动故障切换，还是纯粹的数据冗余备份。
主从复制（Replication）
最常用、最成熟的 MySQL 高可用基础方案。一个主库（Master）负责写入，多个从库（Slave）异步或半同步拉取 binlog 并重放，实现读写分离和数据备份。
- 优点：部署简单、对应用侵入小、支持一主多从横向扩展读能力
- 注意点：默认异步复制存在主从延迟；主库宕机需手动或借助工具（如 MHA、Orchestrator）提升从库为主库
- 建议搭配半同步复制（semisync）+ GTID + 延迟监控，提升数据安全性和运维可控性
MySQL Group Replication（MGR）
MySQL 官方提供的基于 Paxos 协议的多主/单主集群方案，内置自动故障检测、成员管理与数据一致性保障，是 MySQL 5.7.17+ 原生支持的企业级集群选项。
- 支持单主模式（推荐生产使用）和多主模式（需严格规避冲突写入）
- 节点间通过组通信引擎（XCom）保证事务原子广播，具备强一致性语义
- 需配合 MySQL Router 实现客户端自动路由和故障转移，不依赖外部中间件
MySQL InnoDB Cluster（生态整合方案）
基于 MGR 构建的“一站式”高可用解决方案，由 MySQL Shell、MySQL Router 和 Group Replication 三部分组成，提供命令行一键部署、状态可视化、自动修复等能力。
- 适合希望快速落地标准集群、减少定制开发的中小团队
- MySQL Shell 中执行 dba.deploySandboxInstance() 或 dba.createCluster() 即可初始化集群
- 本质仍是 MGR，但封装了大量运维逻辑，降低了使用门槛
第三方中间件集群方案（如 MyCat、ShardingSphere、ProxySQL）
这类方案本身不改变 MySQL 内核，而是通过代理层实现分库分表、读写分离、SQL 路由、熔断限流等功能，适用于超大规模数据或复杂业务分片场景。
- MyCat 侧重分片，适合需要水平拆分的 OLTP 系统
- ShardingSphere（JDBC/Proxy）更灵活，支持混合部署与高级治理能力
- ProxySQL 主打高性能 SQL 路由与缓存，常用于优化主从负载均衡与慢查询拦截
- 注意：引入中间件会增加链路复杂度与排查成本，应优先评估是否真需分片
不复杂但容易忽略的是：无论选哪种集群，备份策略、监控告警（复制延迟、节点状态、QPS/TPS）、定期故障演练，才是保障稳定的核心环节。
