MySQL高可用是保障数据库服务持续稳定运行的核心能力，也是后端开发、DBA岗位面试中的必考内容，掌握完整的高可用知识体系能帮助求职者更好地应对面试提问。
MySQL高可用基础：主从复制
主从复制是MySQL高可用架构的底层基础，几乎所有高可用方案都依赖主从复制实现数据同步，面试中常考其工作原理和同步模式。
主从复制核心流程
主从复制主要分为三个步骤：
- 主库将数据的变更记录写入二进制日志binlog
- 从库的IO线程拉取主库的binlog，写入本地的中继日志relay log
- 从库的SQL线程读取relay log，重放其中的SQL语句完成数据同步
常见同步模式对比
不同同步模式的数据一致性和性能表现不同，面试中常要求对比三者的差异：
| 同步模式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 异步复制 | 主库写入binlog后立即返回，不等待从库确认 | 性能最好 | 主库宕机可能丢数据 |
| 半同步复制 | 主库等待至少一个从库接收binlog并返回确认后才返回 | 数据安全性更高，最多丢一个事务 | 性能略低于异步复制 |
| 全同步复制 | 主库等待所有从库都接收并应用binlog后才返回 | 数据强一致 | 性能最差，可用性低 |
常见MySQL高可用架构方案
基于主从复制衍生出了多种高可用架构，面试中需要掌握各方案的实现原理、优缺点和适用场景。
MMM架构
MMM即Multi-Master Replication Manager，是早期常用的MySQL高可用方案，支持双主多从架构。
MMM通过监控MySQL实例状态，当主库故障时自动将写VIP切换到备用主库，同时调整从库的主库指向。其缺点是存在脑裂风险，且写节点只有单个可用，现在使用场景已经较少。
MHA架构
MHA即Master High Availability，是目前企业中使用较多的高可用方案，专注于主从架构的故障切换。
MHA的Manager节点会定期检查主库状态，主库故障时自动从从库中选举出新的主库，完成故障切换，整个过程通常只需要几十秒。它支持半同步复制，能最大程度保障数据不丢失，缺点是管理节点本身需要额外做高可用。
Group Replication（MGR）
MGR是MySQL官方提供的组复制方案，基于Paxos协议实现数据强一致，支持多主和单主模式。
单主模式下只有一个节点可写，其他节点只读，主节点故障后自动选举新主；多主模式下所有节点都可写，会自动处理冲突。MGR的优势是原生支持、数据强一致，缺点是要求MySQL版本在5.7.17以上，对网络稳定性要求较高。
面试高频问题解析
主从延迟怎么解决
主从延迟是高可用场景下的常见问题，面试中常考优化方案：
- 优化主库写入性能，减少大事务，避免单事务操作过多数据
- 提升从库硬件配置，尤其是磁盘IO和CPU性能
- 从库开启并行复制，MySQL 5.7及以上支持基于GTID的并行复制
- 业务层面避免对延迟敏感的查询直接读从库，或者采用缓存兜底
故障切换时如何保障数据一致性
可以结合半同步复制和MHA这类方案回答：半同步复制保证主库宕机时已经提交的事务至少同步到一个从库，MHA切换时会对比所有从库的relay log，选择同步数据最完整的从库作为新主，同时补全差异数据，最大程度避免数据丢失。
怎么判断主从复制是否正常
可以在从库执行SHOW SLAVE STATUSG命令，查看Slave_IO_Running和Slave_SQL_Running两个字段是否都为Yes，同时关注Seconds_Behind_Master字段的值，该值表示从库落后主库的秒数，为0表示无延迟。
-- 查看从库复制状态 SHOW SLAVE STATUSG -- 关键字段说明 -- Slave_IO_Running: IO线程运行状态，Yes为正常 -- Slave_SQL_Running: SQL线程运行状态，Yes为正常 -- Seconds_Behind_Master: 从库落后主库的秒数，NULL表示异常
高可用方案的选型建议
面试中如果被问到如何选择高可用方案，可以结合业务场景回答：
- 如果是小型业务，对数据一致性要求不高，可选用MMM或者简单的主从+手动切换
- 如果是中型业务，要求自动故障切换且数据安全性较高，优先选择MHA+半同步复制
- 如果是大型业务，MySQL版本符合要求，追求原生支持和强一致，可选择MGR架构
MySQL高可用主从复制MMMMHAGroup_Replication修改时间：2026-07-21 20:21:38