MySQL主从自动切换需借助外部工具实现，核心是主库宕机时快速安全提升从库为新主，并避免脑裂、数据丢失；推荐Orchestrator、MHA等方案，须配套半同步复制、统一监控与定期演练。
MySQL 主从自动切换不是 MySQL 原生支持的功能，需借助外部工具或自建逻辑实现。核心目标是：当主库宕机时，快速、安全地将一个健康从库提升为
新主库，并更新应用连接配置（或通过中间层路由），同时避免脑裂、数据丢失和重复写入。
一、明确切换前提与风险点
自动切换的前提不是“只要主挂了就切”，而是满足一系列安全条件：
-
主库真实不可用：需排除网络闪断、临时高负载等误判；建议至少两个监控节点共同探测（如 MHA 的多节点仲裁）
-
候选从库数据最新：优先选
Seconds_Behind_Master = 0 且 IO/SQL 线程均运行正常的从库；若多个满足，再比对 Exec_Master_Log_Pos 和 Relay_Master_Log_File 确定最接近主库的节点
-
无脑裂风险：必须确保旧主库彻底离线（如通过 STONITH 或强制关机），否则可能双主写入导致数据冲突
-
GTID 或位点可追溯：强烈建议开启 GTID（
gtid_mode=ON），便于故障后精准找主、补数据、重搭从库
二、主流可靠方案选型对比
不推荐纯脚本轮询 + kill process 的方式，稳定性差、边界情况多。生产环境建议以下方案：
-
MHA（Master High Availability）：老牌成熟方案，支持自动选主、VIP 漂移、SSH 免密操作、在线手动切换；缺点是依赖 Perl、维护渐少，但稳定可用
-
Orchestrator：Go 编写，Web 界面友好，支持自动故障转移、拓扑发现、集群分组、人工干预开关；可对接 Consul/Etcd 实现服务发现
-
ProxySQL + 自动化脚本：利用 ProxySQL 的 hostgroup 主从权重+健康检查，配合外部脚本监听 failover 事件，调用
mysql -e "STOP SLAVE; RESET SLAVE ALL;" 等命令完成角色调整，再刷新 ProxySQL 配置
-
基于 Kubernetes 的 Operator（如 PressLabs MySQL Operator）：云原生场景首选，自动管理 StatefulSet、PVC、主从关系、备份恢复，内置切换逻辑
三、关键操作步骤（以 Orchestrator 为例）
实际切换过程不是“一键”，而是分阶段可控执行：
-
探测阶段：Orchestrator 每秒检测主库心跳（默认通过普通账号执行
SELECT 1），连续失败 N 次触发判断
-
分析阶段：扫描所有从库，过滤掉延迟大、SQL 线程异常、版本不兼容的节点，选出最优候选（支持自定义权重）
-
切换阶段：停止候选从库复制 → 执行
STOP SLAVE; RESET SLAVE ALL; → 将其设为只读关闭 → 更新其 read_only=OFF → 在其他从库上执行 CHANGE MASTER TO ... 指向新主
-
通知与收敛：发送 Slack/邮件告警；更新 DNS 记录或配置中心（如 Nacos）中的数据库地址；可回调自定义脚本（如刷新应用连接池）
四、必须配套的基础保障
没有这些，自动切换反而放大故障：
-
半同步复制（Semisync）开启：保证主库提交事务前至少一个从库已收到 relay log，降低切换时的数据丢失概率（
rpl_semi_sync_master_enabled=ON）
-
统一监控告警体系：Zabbix/Prometheus + Grafana 监控复制延迟、线程状态、磁盘空间、连接数，异常时联动 Orchestrator 或人工介入
-
定期演练与日志审计：每月至少一次模拟主库 kill -9，验证切换耗时（建议 ≤ 30 秒）、数据一致性（用 pt-table-checksum 校验）、应用是否自动重连
-
应用层适配：连接串不要写死 IP；使用支持重连+读写分离的驱动（如 MySQL Connector/J 的
autoReconnect=true&failOverReadOnly=false）；或统一走中间件（ShardingSphere、MyCat）屏蔽底层变化
