MySQL主库故障转移需自动化实现，核心是确保从库复制健康、启用半同步或MGR保障一致性，借助MHA等工具自动切换，并完成新主库重置、从库重连及配置更新等收尾操作。
MySQL 主库故障转移是高可用架构中的核心环节，关键在于快速、准确地将一个从库提升为新的主库，并确保业务无感知或影响最小。这不能靠人工操作，必须依赖可靠的自动化机制和严谨的前置准备。
确保复制状态健康且延迟可控
故障转移的前提是从库数据必须跟得上主库。如果从库延迟严重，强行切换会导致数据丢失。
- 定期检查 Seconds_Behind_Master，生产环境建议控制在 1 秒以内（半同步 + relay_log_purge=ON + 合理网络）
- 确认 IO_THREAD 和 SQL_THREAD 均为 Yes，且 Slave_SQL_Running_State 显示 “executing” 而非 “waiting” 或卡住
- 开启 relay_log_recovery=ON，避免崩溃后 relay log 不完整导致恢复失败
选择合适的一致性保障模式
异步复制无法保证主从强一致，故障转移时可能丢事务；半同步（semi-sync）可大幅降低风险，但需权衡性能与可靠性。
- 推荐部署 semisync_master_enabled=ON + semisync_slave_enabled=ON，并设置 rpl_semi_sync_master_timeout=10000000（10秒），避免主库因等待响应而长时间阻塞
- MySQL 5.7+ 可考虑 Group Replication（MGR），自带自动选主和冲突检测，但对网络和配置要求更高
- 避免仅依赖 binlog position 手动切换——位置相同不等于数据一致（如部分事务未提交）
使用成熟工具实现自动故障转移
人工切换风险高、耗时长，应交由专业高可用组件完成决策与执行。
- MHA（Master High Availability）：轻量稳定，支持在线切换与自动failover，需配合SSH免密和自定义脚本做VIP漂移或DNS更新
- Orchestrator：可视化强，支持拓扑发现、自动修复、API驱动，适合中大型集群
- ProxySQL + 自定义探测脚本：通过 ProxySQL 的 hostgroup 自动下线故障主库，结合外部脚本触发提升操作（需自行保障幂等性和状态同步）
切换后必须验证与收尾
故障转移不是“提升完就结束”，后续动作直接影响服务稳定性。
- 新主库执行 RESET MASTER，清空旧 binlog 并生成新序列号，防止后续从库拉取错误日志
- 所有原从库重新执行 CHANGE MASTER TO 指向新主库，注意使用 MASTER_AUTO_POSITION=1（GTID 模式下更安全）
- 更新应用连接配置（或通过 VIP/DNS/配置中心同步变更），并验证读写流量是否正常路由
- 保留旧主库为只读备用，待确认无误后再决定是否重建为从库或下线
