主库宕机后应选Relay_Master_Log_File与Exec_Master_Log_Pos值最大的从库升主，先停IO线程并确认SQL线程已重放完所有relay log，再执行STOP SLAVE、RESET MASTER、清理info文件、开启binlog并重启；其余从库需重新CHANGE MASTER TO新主并验证同步状态。
主库宕机后，核心目标是快速选出数据最完整、同步最及时的从库，将其提升为新主库，并让其余从库重新指向它。整个过程不复杂但容易忽略关键校验点。
确认哪个从库数据最新
不能凭感觉选，必须比对每个从库的复制位置：
- 在各从库执行 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 解析也需同步切换，避免继续往宕机的旧主发请求
