主从复制+读写分离为基础方案，MHA实现快速故障切换，MGR提供强一致性与自动容错，InnoDB Cluster集成管理简化部署，双主+Keepalived需慎用；选型需根据业务对一致性、恢复时间及运维能力的要求综合考量。
在现代互联网应用中，数据库作为核心组件之一，其稳定性与可用性直接影响业务的连续性。MySQL 作为最流行的开源关系型数据库之一，如何搭建高可用架构成为运维和架构师关注的重点。下面从常见方案入手，解析 MySQL 高可用的实现方式及搭建思路。
主从复制 + 读写分离
这是最基础的高可用方案，通过配置主库（Master）和一个或多个从库（Slave），实现数据的异步复制。
特点：
- 主库负责写操作，从库负责读操作，实现读写分离，减轻主库压力
- 当主库宕机时，需手动或通过脚本将某个从库提升为新的主库
- 存在数据延迟风险，不适合对一致性要求极高的场景
搭建要点：
- 开启主库的 binlog，并配置 server-id
- 从库配置 relay-log 和 server-id，执行 CHANGE MASTER TO 指向主库
- 使用中间件如 MyCat、ProxySQL 或应用程序层实现读写分离
MHA（Master High Availability）
MHA 是一个成熟的 MySQL 高可用解决方案，能够在 30 秒内完成主库故障自动切换。
工作原理：
- 监控主库状态，发现宕机后自动选择一个数据最新的从库作为新主库
- 将其他从库重新指向新主库，完成切换
- 支持在线主库切换，用于计划内维护
优点：
- 切换速度快，数据不丢失（前提是半同步复制）
- 部署相对简单，社区活跃
缺点：
- 需要额外管理 MHA Manager 节点
- 原生不支持多主，仅适用于一主多从架构
MySQL Group Replication（MGR）
MySQL 官方提供的基于 Paxos 协议的组复制技术，支持多主或单主模式。
核心优势：
- 数据强一致性，事务提交前需多数节点确认
- 自动故障检测与节点剔除
- 支持弹性扩展，动态加入或退出节点
部署要求：
- MySQL 5.7.17+，推荐使用 8.0 版本
- 各节点间网络延迟低，带宽稳定
- 需配合 MySQL Router 实现客户端透明访问
MGR 适合对数据一致性要求高、希望摆脱外部依赖的中大型系统。
InnoDB Cluster
InnoDB Cluster 是 Oracle 推出的完整高可用方案，底层基于 MGR，上层集成 MySQL Shell 和 MySQL Router。
组件说明：
- MySQL Shell：提供 AdminAPI，简化集群管理
- MySQL Router：自动路由客户端请求到主节点或只读从节点
- MGR：保障数据复制与节点一致性
通过一条命令即可搭建高可用集群，适合希望快速部署且减少运维复杂度的团队。
双主 + Keepalived（慎用）
两个 MySQL 实例互为主从，通过 Keepalived 虚拟 IP 实现故障转移。
风险提示：
- 容易因脑裂导致数据冲突
- 自增主键重复、唯一索引冲突等问题频发
- 仅建议在特定场景下使用，如纯日志写入类业务
若必须使用，应配置不同的 auto_increment_offset 和 auto_increment_increment。
基本上就这些主流方案。选择哪种架构，取决于你的业务对数据一致性、故障恢复时间、运维能力的要求。小规模系统可用 MHA + 主从，追求自动化可选 InnoDB Cluster，大规模高并发场景建议深入优化 MGR 架构。关键是做好备份、监控和定期演练，才能真正实现高可用。不复杂但容易忽略。
