mysql主从架构不支持自动切换，需依赖外部高可用工具实现容灾；必须满足主库不可恢复、从库同步完成、启用gtid、旧主隔离等前提；推荐mha、orchestrator、proxysql+脚本或k8s operator方案；切换分探测、分析、提升、重连、路由更新五阶段；应用层可用jdbc多地址兜底。
核心前提：不能只靠“主挂了就切”
盲目切换比不切换更危险。自动切换前必须确认：
• 主库确实不可恢复（不是网络抖动或临时高负载）
• 至少一个从库已完全同步（Seconds_Behind_Master = 0，且 Slave_IO_Running 和 Slave_SQL_Running 均为 YES）
• 启用 GTID（gtid_mode=ON），否则无法精准判断数据一致性
• 旧主库已隔离（如通过 STONITH 或强制断电），防止脑裂写入
推荐方案：选成熟工具，别手写脚本
生产环境不建议用简单 ping + kill 的轮询脚本，边界情况多、可靠性低。主流可靠选择有：
• MHA：Perl 编写，稳定成熟，支持 VIP 漂移和 binlog 日志抢救，适合中小规模集群
• Orchestrator：Go 开发，自带 Web 界面，支持拓扑发现、人工干预开关、Consul 集成，运维体验好
• ProxySQL + 自动化脚本：利用 ProxySQL 的 hostgroup 权重与健康检查，配合外部脚本触发 STOP SLAVE; RESET SLAVE ALL; 和角色变更
• Kubernetes Operator（如 PressLabs MySQL Operator）：云原生场景首选，自动管理 StatefulSet、PVC、复制关系及切换逻辑
关键动作：切换不是“一键”，而是分阶段执行
以 Orchestrator 为例，一次安全切换包含：
• 探测：每秒执行 SELECT 1，连续失败 N 次才触发判定
• 分析：筛选出延迟低、线程正常、版本兼容的候选从库，按 GTID 位置或日志位点排序选最优
• 提升：对候选库执行 STOP SLAVE; RESET SLAVE ALL;，关闭 read_only，设为新主
• 重连：其他从库自动执行 CHANGE MASTER TO 指向新主，无需人工干预
• 路由更新：应用层需配合——要么通过 VIP/域名解析切换，要么由 ProxySQL/中间件动态调整流量
应用层兜底：JDBC 也能做基础故障转移
如果暂无中间件或高可用工具，Java 应用可利用 mysql-connector-java 内置能力：
• 连接 URL 写成：jdbc:mysql://192.168.0.1:3306,192.168.0.2:3306/mydb?allowMultiQueries=true
• 驱动会自动尝试列表中第一个地址，失败后切换下一个
• 注意：这只解决连接建立阶段的故障转移，不处理已建立连接的中断、事务回滚或读写分离逻辑，仅作为轻量级兜底手段
