可切换需满足Seconds_Behind_Master为0且Slave_IO_Running、Slave_SQL_Running均为Yes；否则可能丢数据。须校验Exec_Master_Log_Pos与Relay_Master_Log_File是否与主库File/Position一致，并确保无未回放relay log。
主从复制中断后如何快速判断是否可切换
MySQL 主从复制故障时，不能直接切，得先确认从库数据是否已追平、是否处于可靠状态。关键看 Seconds_Behind_Master 是否为 0，且 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes。如果 IO 线程已断（比如网络抖动），但 SQL 线程还在跑，Seconds_Behind_Master 可能为 NULL 或负值，此时切过去会丢数据。
- 执行
SHOW SLAVE STATUS\G，重点检查Seconds_Behind_Master、Exec_Master_Log_Pos、Relay_Master_Log_File - 对比主库的
SHOW MASTER STATUS中的File和Position，若完全一致，说明已追平 - 若从库有未执行的
relay log，需先运行START SLAVE SQL_THREAD等其回放完，别只启 IO
手动提升从库为主库的实操步骤
切换不是改个配置就完事，核心是让原从库“自立门户”，同时防止脑裂和双写。必须停掉原主库的写入（或确认其已不可用），再在从库上执行以下动作：
- 在从库执行
STOP SLAVE，确保不再拉取和应用日志 - 执行
RESET MASTER—— 这步很重要，清空本地 binlog 并新建一个，避免后续新主库日志与旧主冲突 - 修改
my.cnf：设置server-id为唯一新值（不能和原主库重复），开启log-bin，并确认binlog_format=ROW - 重启 MySQL（可选，但建议做，确保配置生效且无残留 relay log 状态）
注意：RESET MASTER 会清空所有 binlog，所以仅限新主库首次启用前执行；切勿在还有其他从库连着它时操作。
应用端如何安全重连新主库
数据库层切换完成，不等于业务就恢复了。应用连接池往往缓存着旧主库地址，甚至事务可能卡在半路。必须配合应用侧做三件事：
- 确认所有写请求已停止发往原主库（可通过防火墙 DROP、VIP 摘除、或中间件下线节点）
- 清空应用连接池（如 Druid 的
closeIdleConnections()，HikariCP 的evict()），避免复用旧连接 - 更新配置中心或部署脚本中的数据库地址——不要只改一台机器，要全量同步
- 如果用了读写分离中间件（如 MyCat、ShardingSphere），需人工触发主节点切换命令，例如
RELOAD @@config或调用 API 切换 writeHost
切换后最容易被忽略的验证点
很多人切完就以为结束了，结果第二天发现主键冲突、自增错乱、或者某个小表没同步。真正可靠的验证不是看能不能连上，而是看数据一致性：
- 检查新主库的
auto_increment_offset和auto_increment_increment—— 若之前是双主或多主架构，这些值可能遗留，导致 INSERT 报错Duplicate entry for key 'PRIMARY' - 运行
pt-table-checksum对比新主和剩余从库（如有）的数据行级一致性，尤其关注大表和高频更新表 - 查
SELECT @@server_id和SHOW VARIABLES LIKE 'server_id'，确保新主的server_id不与其他节点重复，否则后续加从库会报错Could not find first log file name in binary log index file
灾备切换不是一次性操作，而是一组强依赖的原子动作。漏掉任意一环，比如忘记 RESET MASTER 或没清连接池，都可能引发后续数据异常，且问题往往延迟暴露。
