主从切换前必须确认Seconds_Behind_Master为0、Slave_IO_Running和Slave_SQL_Running均为Yes、原主库无长事务及未提交写入；需执行FLUSH TABLES WITH READ LOCK、MASTER_POS_WAIT等待追平、重置复制源并验证新主从数据一致性和连接指向。
主从切换前必须确认的 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，线上数据就对不上了。 
