主库宕机后，核心目标是快速选出数据最完整、同步最及时的从库，将其提升为新主库，并让其余从库重新指向它。整个过程不复杂但容易忽略关键校验点。
确认哪个从库数据最新
不能凭感觉选，必须比对每个从库的复制位置：
在各从库执行 SHOW SLAVE STATUS\G，重点看 Relay_Master_Log_File 和 Exec_Master_Log_Pos 这两个值组合起来代表“已成功执行到主库哪条 binlog 的哪个位置”。数值越大，说明同步越靠前、丢的数据越少 如果多个从库数值一致，任选其一即可；若差异明显，优先选最大值的那个确保从库已完全重放 relay log
即使 SQL 线程显示运行中，也可能还有未执行完的 relay 日志：
先执行 STOP SLAVE IO_THREAD;，停止接收新日志 再执行 SHOW PROCESSLIST;，观察是否有线程状态为 Has read all relay log 等所有 relay log 都被 SQL 线程应用完毕（即无 pending 的事件），再进行下一步将选定从库升级为新主库
这步涉及配置变更和元数据清理：
登录该从库，执行 STOP SLAVE; 和 RESET MASTER; 进入 MySQL 数据目录（如 /application/mysql/data/），删除 master.info 和 relay-log.info 编辑 /etc/my.cnf：开启 log-bin，注释掉 read-only、log-slave-updates 等限制写入的参数 重启 MySQL 服务，使其具备写入和生成 binlog 的能力其他从库重新指向新主库
原主库恢复前，所有读写流量都需切到新主库：
在其余从库上执行：STOP SLAVE; 用 CHANGE MASTER TO 指向新主库 IP，并指定新主库当前的 File 和 Position（通过新主库的 SHOW MASTER STATUS 获取） 执行 START SLAVE; 并用 SHOW SLAVE STATUS\G 确认两个线程均为 Yes，且 Seconds_Behind_Master = 0 应用层连接字符串或 DNS 解析也需同步切换，避免继续往宕机的旧主发请求
