主库宕机后5分钟内完成高可用切换，需稳判断（三重验证主库状态）、快操作（选同步完成且日志最全的从库晋升）、保一致（gtid/位点校验、重连上下游并滚动切流）。
主库宕机后快速切换到从库上线，核心是“稳判断、快操作、保一致”。不能只看告警就切，也不能盲目执行命令——关键在确认状态、选对节点、控制节奏。整个过程5分钟内可完成，前提是日常配置已就绪（如开启GTID、半同步、binlog保留充足）。
第一步：确认主库是否真不可用
跳过主观猜测，用三类验证快速下结论：
- 网络层：ping + telnet 主库IP和端口（如3306），任一不通且持续超15秒，记为初步异常
- 服务层：用监控账号执行
mysql -h 主库IP -u monitor -e "SELECT 1"，失败即服务无响应 - 日志层（可选但重要）：若还能SSH进主库，立即运行
mysql -e "SHOW MASTER STATUS"，记录当前File和Position——这是后续回切或补数据的唯一依据
注意：单点探测易误判，生产环境建议由至少两个独立监控节点共同确认；若主库仅短暂卡顿（如IO打满），应等待30秒再重试，避免误切。
第二步：选出最合适的从库晋升
不是所有从库都能直接顶上。优先选择满足以下全部条件的节点：
-
同步完成：执行
SHOW SLAVE STATUS\G，Seconds_Behind_Master = 0，且Slave_IO_Running和Slave_SQL_Running均为Yes - 日志完整：查看Relay_Master_Log_File与Exec_Master_Log_Pos，对比其他从库，选数值最接近主库原File/Position的那个
- 配置就绪：已开启log_bin、binlog_format=ROW，且read_only=OFF可临时关闭（或已配好提升脚本）
若多个从库都满足，GTID环境下直接比Retrieved_Gtid_Set与Executed_Gtid_Set的并集大小；非GTID环境则比Exec_Master_Log_Pos值最大者。
第三步：执行安全晋升操作
在选定的从库上依次执行（全部使用mysql客户端，非shell命令）：
-
STOP SLAVE;—— 停止复制，切断与旧主关联 -
RESET SLAVE ALL;—— 清除所有复制元数据（含master.info、relay-log.info等） -
SET GLOBAL read_only = OFF;—— 允许写入（如原配置为ON） -
FLUSH PRIVILEGES;—— 确保权限生效（尤其新增复制用户时）
完成后立刻执行SHOW MASTER STATUS;，记录新主库的File和Position——这是其他从库重新接入所需的凭证。
第四步：重连其余从库与应用
切换不是单点动作，需同步更新上下游：
-
其他从库：在每台从库上执行
CHANGE MASTER TO MASTER_HOST='新主IP', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='刚才记下的File', MASTER_LOG_POS=刚才记下的Position;，再START SLAVE; - 应用连接：修改数据库连接池配置（如JDBC URL、DNS CNAME、或ProxySQL hostgroup权重），指向新主库IP+端口；务必滚动发布，避免瞬时连接风暴
-
原主库处理：修复后不要直接启动复制，先
RESET MASTER;清空旧binlog，再以从库身份接入新主——否则可能因位点冲突导致SQL线程报错
切换完成后，紧盯SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Last_IO_Error，10分钟内无延迟增长、无错误即视为稳定上线。
