MySQL主从复制本身不支持自动故障转移，需依赖MHA、Orchestrator、ProxySQL+MGR、Keepalived+VIP等外部方案实现高可用，InnoDB Cluster为官方推荐的内核级解决方案。
主从复制本身不支持自动故障转移
MySQL原生的主从复制只是数据同步机制，不具备故障检测和主库切换能力。当主库宕机时，从库不会自动升级为主库，需要人工干预或借助外部工具实现高可用。
常见自动故障转移方案
主流做法是组合使用监控、选举和切换工具，形成闭环流程：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- MHA（Master High Availability）：老牌成熟方案，通过Perl脚本监控主库状态，发现故障后自动选一个最优从库提升为主库，并重写其他从库的复制源。需配置SSH免密、VIP漂移或DNS更新，适合中小规模。
- Orchestrator：基于Web界面的Go语言工具，支持自动探测拓扑、主库故障识别、安全主从切换和恢复。可对接Consul或etcd做服务发现，兼容GTID，对运维友好。
- ProxySQL + MGR/InnoDB Cluster：用ProxySQL做读写分离和健康检查，后端接入MySQL Group Replication（MGR），由组内多数派自动完成故障检测与新主选举。这是官方推荐的高可用路径，强一致性好，但要求MySQL 5.7+且全部节点配置一致。
- Keepalived + VIP + 脚本：轻量级方案，在主库所在服务器部署Keepalived，绑定虚拟IP（VIP）。配合自定义脚本检测mysqld进程和复制状态，异常时释放VIP，备用节点抢占并启动MySQL服务。需注意脑裂风险，建议搭配STONITH或仲裁机制。
关键前提和注意事项
无论选哪种方案，以下几点必须提前确认：
- 所有节点启用GTID，避免切换后复制中断或数据错乱；
- 从库设置read_only=ON（除超级用户外禁止写入），防止误操作污染数据；
- 确保binlog格式为ROW，保障复制精确性；
- 定期验证主从延迟和复制线程状态，延迟过大时禁止切换；
- 切换过程要更新应用连接地址（如VIP、DNS、配置中心），否则客户端仍连旧主IP导致失败。
更现代的选择：MySQL InnoDB Cluster
基于Group Replication构建，内置自动故障检测、分布式恢复和单主模式控制。使用MySQL Shell一键部署，自带MySQL Router实现透明路由。适合追求开箱即用、强一致性、且能接受MySQL 8.0+版本约束的场景。它把高可用逻辑下沉到数据库内核层，比外挂工具更可靠，但对网络稳定性和节点数量（至少3个）有硬性要求。
