主从切换后数据不一致的根本原因并非切换动作本身，而是切换前未确认Seconds_Behind_Master归零、未对齐Exec_Master_Log_Pos与Read_Master_Log_Pos，或忽略并行复制延迟；典型表现为新主库查不到旧主刚写入的数据或出现Duplicate entry等错误。
主从切换后为什么会出现数据不一致？
根本原因不是切换动作本身，而是切换前未确认 Seconds_Behind_Master 归零、未等待 Exec_Master_Log_Pos 与 Read_Master_Log_Pos 对齐，或忽略从库的并行复制延迟（如 slave_parallel_workers > 0 时，Seconds_Behind_Master 可能为 0 但实际还有未应用的事务）。
典型表现：切换后新主库上查不到刚在旧主库写入的数据，或者出现主键冲突、唯一索引报错 Duplicate entry。
- 务必用
SHOW SLAVE STATUS\G检查SQL_Delay是否非零（人为延迟复制会被忽略） - 若启用了 GTID，需比对
Retrieved_Gtid_Set和Executed_Gtid_Set是否完全相等，不能只看Seconds_Behind_Master - 半同步复制下，
Rpl_semi_sync_master_status为ON仅表示机制启用，不代表当前事务已半同步成功
切换前必须执行的三步校验
这不是可选步骤，是防止脑裂和丢数据的底线操作。建议封装成脚本调用：
- 执行
STOP SLAVE;，再运行SELECT MASTER_POS_WAIT('<code>File',Position, 60); —— 这里的File/Position来自SHOW MASTER STATUS在旧主上的输出，确保从库至少追平旧主的最新位点 - 检查
SHOW PROCESSLIST中是否有State: Reading event from the relay log或长时间Waiting for semi-sync ACK的线程，这类线程可能卡住复制 - 对关键业务表执行
CHECKSUM TABLE t1, t2（注意：该语句会加读锁，避开高峰期；MySQL 8.0.25+ 支持NO_WRITE_TO_BINLOG修饰符降低影响）
如何安全提升从库为新主库？
直接 RESET SLAVE ALL + CHANGE MASTER TO 是危险操作，尤其当原主库尚未彻底下线时。正确路径是：
- 先在目标从库执行
STOP SLAVE;，再RESET SLAVE ALL;清除所有复制元数据（包括master.info和relay-log.info） - 如果原主库仍可访问，用
SHOW MASTER STATUS获取其最新File和Position，并在新主库上执行CHANGE MASTER TO MASTER_HOST='old_master_ip', ...配置反向复制（用于后续回切或补数据） - 若原主库已宕机且无 binlog 保留，新主库必须立即执行
SET GLOBAL read_only=OFF;，同时修改配置文件中read_only=0并重启（否则应用写入会报错ERROR 1290 (HY000)）
切换后最容易被忽略的三个细节
很多团队做完切换就认为万事大吉，但以下三点常在数小时后暴露问题：
-
auto_increment_offset和auto_increment_increment如果在多主或环形架构中没重设，新主库插入新记录会和旧主残留连接产生主键冲突 - 从库的
relay_log_purge=ON默认开启，但切换后它不再自动清理 relay log——这些文件可能占满磁盘，需手动PURGE RELAY LOGS BEFORE 'mysql-relay-bin.000010'; - 监控项如
mysql_slave_seconds_behind_master在 Prometheus 中仍指向旧指标，需立刻更新 exporter 配置或标签，否则告警永远“误报”
