MySQL高可用核心是自动快速无损切换，主流方案为主从复制+MHA/Orchestrator等工具，辅以半同步、三节点、VIP/Router实现透明切换；MGR原生集群适合强一致性场景，需单主、GTID、低延迟网络；须覆盖监控、定期演练、避免单点、同步备份。
MySQL 高可用（HA）的核心目标是：当主节点故障时，系统能自动、快速、无数据丢失地切换到备用节点，持续对外提供服务。不依赖人工干预，且尽量减少主从延迟和脑裂风险。
基于主从复制 + 故障自动切换（推荐主流方案）
这是生产环境最成熟、可控性最强的架构，典型组合是 MySQL 主从复制 + MHA / Orchestrator / MySQL Router + VIP 或 DNS 切换。
- 主从异步/半同步复制：优先启用半同步（semi-sync），确保至少一个从库收到并写入 relay log 后，主库才返回成功，降低主库宕机时的数据丢失风险；
- 部署至少 3 节点：1 主 + 2 从（其中 1 个可设为候选主），避免双节点下网络分区引发脑裂；
- 使用高可用管理工具：MHA 可自动检测主库宕机、选择最佳从库提升为主、重置复制拓扑；Orchestrator 支持可视化与自动化修复，兼容 GTID 更稳定；
- 客户端透明切换：配合 VIP 漂移或 MySQL Router 的自动重路由，应用无需修改连接地址；DNS 方式需控制 TTL 较低（如 10 秒），但存在缓存延迟，适合对切换时间要求不极致的场景。
基于 MySQL Group Replication（MGR）的原生集群
MGR 是 MySQL 5.7.17+ 官方提供的多主/单主模式分布式集群方案，基于 Paxos 协议实现强一致性，适合对一致性要求高、希望减少第三方组件依赖的团队。
- 单主模式更稳妥：默认开启，仅允许一个节点写入，其余只读，规避多主冲突和回滚复杂性，也更易对接现有应用；
- 必须启用 GTID 和 binlog row 格式，且所有节点 server_id、group_replication_group_name 等配置需严格一致；
- 网络质量敏感：节点间心跳与消息同步依赖低延迟、高可靠局域网，跨机房部署需谨慎评估 RTT 和丢包率；
- 需配套路由层：官方推荐 MySQL Router（支持自动感知主节点变更），或用 ProxySQL 自定义读写分离与故障转移逻辑。
关键设计细节不能忽略
再好的架构，若基础配置不当，也会导致 HA 失效。
- 监控全覆盖：不仅要监控 MySQL 进程存活，更要采集复制延迟（Seconds_Behind_Master）、IO/SQL 线程状态、GTID_EXECUTED 一致性、磁盘空间、连接数等指标，告警响应时间应控制在 30 秒内；
- 定期演练切换流程：每季度至少一次模拟主库 kill -9 或断网，验证切换是否自动、数据是否一致、应用是否恢复连接；
- 避免单点依赖：MHA manager 自身建议部署双机 + keepalived；Orchestrator 可集群化部署；VIP 方案中 keepalived 也需双活防止单点失效；
- 备份与恢复能力同步建设：HA 不等于数据安全，仍需每日全量 + binlog 增量备份，并验证可恢复性——故障切换后若发现数据异常，备份是最后一道防线。
不推荐单独使用的方案
某些方案因稳定性、维护成本或适用场景受限，一般不作为主力 HA 架构：
- 纯双主（Active-Active）+ auto-increment offset：易因写冲突、死锁、自增键重复等问题导致复制中断，运维难度大；
- Heartbeat + DRBD：已基本淘汰，DRBD 在云环境兼容性差，切换慢、数据一致性难保障，且无法解决 MySQL 层逻辑故障；
- 仅靠中间件（如 ShardingSphere、MyCat）做 HA：它们本身无故障探测和主从提升能力，需额外集成健康检查与路由更新机制，可靠性取决于外围设计。
高可用不是“搭好就完事”，而是配置、监控、演练、备份四者闭环。选型时优先考虑团队技术储备与运维能力——MHA 上手快，MGR 功能强但调优门槛高。真正稳定的 MySQL HA，藏在日志里、监控中、演练后。
