MySQL主从高可用自动切换的核心目标是业务不中断、数据不丢失、切换可回退；需确保ROW格式Binlog开启、双复制线程活跃、推荐启用半同步复制，并覆盖“发现—决策—执行—验证—修复”全链路。
要实现 MySQL 主从架构下的高可用自动切换，关键不在于堆砌组件，而在于理清角色分工、数据一致性保障和故障响应逻辑。自动切换本身不是目的，业务不中断、数据不丢失、切换可回退，才是核心目标。
主从复制必须可靠，这是自动切换的前提
没有稳定的数据同步，切换就是空中楼阁。重点检查三项：
-
Binlog 必须开启且格式为 ROW：在主库 my.cnf 中配置
log_bin = mysql-bin和binlog_format = ROW，避免语句级复制引发的不一致问题； -
从库复制线程必须双活跃：执行
SHOW SLAVE STATUS\G，确认Slave_IO_Running和Slave_SQL_Running都是 YES，且Seconds_Behind_Master尽量接近 0； -
推荐启用半同步复制：主库安装
rpl_semi_sync_master插件，从库启用rpl_semi_sync_slave，设置超时时间（如 1000ms），确保主库提交前至少一个从库已落盘 relay log，大幅降低故障时的数据丢失风险。
自动切换不能只靠“检测+升主”，必须闭环管理
真正的自动切换系统需覆盖“发现—决策—执行—验证—修复”全链路，常见组合方案如下：
-
Keepalived + VIP + 切换脚本：适合中小规模。Keepalived 监控主库 MySQL 进程和端口，一旦失联，触发脚本在候选从库上执行
STOP SLAVE; RESET SLAVE ALL;，并绑定虚拟 IP（VIP），应用通过 VIP 访问，无需改连接串； -
ProxySQL + 健康检查：更灵活可控。ProxySQL 作为中间代理，持续运行
SELECT 1和SELECT @@read_only检查后端节点状态，自动将写流量路由到唯一read_only=OFF的节点，并支持延迟阈值（如max_replication_lag = 5）拒绝滞后过大的从库参与写入； -
MySQL InnoDB Cluster（官方方案）：适用于 MySQL 8.0+ 环境。基于 Group Replication 多节点强同步，自带自动选主、故障剔除和集群元数据管理，执行
cluster.setPrimaryInstance()即可手动干预，日常完全自治。
切换策略要匹配业务容忍度，不能一刀切
没有绝对“最优”的切换方式，只有更适配当前场景的选择：
-
可靠性优先：要求零数据丢失，允许短暂写不可用。切换前强制等待所有候选从库
Seconds_Behind_Master = 0，再停主库写入、升从库为主，适合金融类核心账务系统； - 可用性优先：允许极少量数据差异，强调快速恢复写能力。监控发现主库宕机即刻触发切换，新主库启动后异步追赶原主库缺失事务（如有），适合用户行为日志、商品浏览等读多写少、最终一致即可的场景；
-
双主热备（Dual-Master）慎用：虽能缩短切换时间，但需严格规避循环复制（依赖
server_id和replicate-same-server-id=OFF），且写冲突风险高，建议仅用于跨机房容灾，且两个实例严格分片写入。
切换后必须验证并修复拓扑，否则只是转移问题
一次成功的切换，不等于高可用落地完成。后续动作同样关键：
- 新主库上线后，立即检查其
read_only是否为 OFF，log_bin是否开启，确保它能继续承担写入并被下游同步； - 原主库恢复后，不要直接拉起就当从库——先
RESET MASTER清空旧 binlog，再CHANGE MASTER TO指向新主库，避免 GTID 冲突或位置错乱； - 所有从库的
MASTER_HOST必须统一更新为新主库地址，可通过 MHA 的masterha_master_switch或自定义脚本批量下发，避免遗漏导致部分从库停滞； - 切换过程全程记录日志，包括触发时间、选定节点、执行命令、耗时、错误码，便于事后复盘和优化阈值设定。
