主从切换前必须确认的 3 个状态
直接执行切换大概率导致数据丢失或复制中断。先检查这三项：
•
SHOW SLAVE STATUS\G中
Seconds_Behind_Master必须为
0（或极小稳定值），不能是
NULL或持续增长
•
Slave_IO_Running和
Slave_SQL_Running都必须是
Yes
• 原主库上
SHOW PROCESSLIST中无长事务、无未提交的
INSERT/UPDATE/DELETE
停写 + 等待同步完成的标准操作
切勿在业务写入中强行切换。真实环境要这样收口：
• 在原主库执行
FLUSH TABLES WITH READ LOCK（会阻塞写，但确保后续 binlog 位置精确）
• 立即执行
SHOW MASTER STATUS，记下
File和
Position
• 到原从库运行
SELECT MASTER_POS_WAIT('xxx-bin.000001', 123456789)，等待返回非 -1值才表示已追平
• 此时再在原主库执行
UNLOCK TABLES
修改复制关系的两步关键命令
角色互换不是改个配置重启就行，必须重置复制源：
• 在**新主库**（原从库）上执行：
STOP SLAVE;
RESET SLAVE ALL;（清空 relay log 和 master.info，避免残留旧配置）
• 在**新从库**（原主库）上执行：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='new_master_ip', SOURCE_PORT=3306, SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_LOG_FILE='mysql-bin.000001', SOURCE_LOG_POS=123456789;
START SLAVE;
切换后必须验证的 3 个点
很多故障出现在“以为切成功了”之后：
• 新主库写入一条带时间戳的测试记录，比如
INSERT INTO test_switch VALUES (NOW());
• 立即在新从库查这条记录是否出现、时间是否一致
• 检查新从库的
SHOW SLAVE STATUS\G中
Seconds_Behind_Master是否保持为
0，且
Retrieved_Gtid_Set和
Executed_Gtid_Set相等（若启用 GTID）
• 特别注意：应用连接字符串里的 host 和端口是否已指向新主库，DNS 缓存或连接池可能仍连着老地址 实际中最容易被跳过的，是原主库上的
FLUSH TABLES WITH READ LOCK和后续的
MASTER_POS_WAIT等待——有人图快直接
STOP SLAVE就切，结果新主库漏掉最后几条 binlog，线上数据就对不上了。
