切换后必须立即执行SHOW SLAVE STATUS\G确认同步完成，重点检查Slave_IO_Running、Slave_SQL_Running为Yes，Seconds_Behind_Master为0，且Exec_Master_Log_Pos或Executed_Gtid_Set与旧主库一致。
切换后立刻查 SHOW SLAVE STATUS\G 看是否真同步完成
很多人以为“切换完成”就等于数据一致，其实只是角色变了，不代表从库已追平。必须立刻在新主库（原从库）上执行 SHOW SLAVE STATUS\G，重点盯三项：
• Slave_IO_Running 和 Slave_SQL_Running 都是 Yes；
• Seconds_Behind_Master 显示为 0；
• Exec_Master_Log_Pos 与旧主库停写时记录的 Position 完全一致（GTID 模式下要核对 Executed_Gtid_Set 是否包含全部事务）。
漏掉任一条件，都说明还有未应用的 binlog，此时做一致性校验就是白忙。
用 pt-table-checksum 校验前必须确认 log_slave_updates=ON
pt-table-checksum 不是直接连从库比数据，而是靠主库写 checksum 记录、从库重放并存入 percona.checksums 表，再比对字段 master_crc 和 this_crc。如果从库没开 log_slave_updates=ON，它根本不会把 checksum 写进自己的 percona.checksums，结果永远显示“0 differences”，但实际可能差一大截。
检查方式：SELECT @@log_slave_updates; 返回 1 才有效。
补救方法：在从库执行 SET GLOBAL log_slave_updates = ON;，然后重启复制（STOP SLAVE; START SLAVE;），再跑校验。
校验大表时别只信 pt-table-checksum 输出的 “OK”
pt-table-checksum 默认只在主库计算、只输出“0 differences found”，这仅代表主库写 checksum 成功，并不表示从库已完成比对。真正要看的是从库上的 percona.checksums 表：
• 登录从库执行：SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_bad = 1;
• 如果有返回行，说明对应表不一致；
• 注意 is_drift 字段为 1 也代表潜在问题（比如分块校验中某块超时跳过）。
常见坑：
• 从库开了 replicate_ignore_db = percona，导致 percona.checksums 表被跳过；
• 复制延迟高，checksum 记录还没来得及同步到从库，就急着查表；
• 工具连接从库用的是主库账号，但从库只给了 SELECT 权限，缺 INSERT/UPDATE 就写不进 checksum 结果。
抽样比对关键字段比校验和更可靠
就算 CHECKSUM TABLE 或 pt-table-checksum 显示一致，也可能掩盖隐式问题：比如 TIMESTAMP 因时区配置不同导致值偏移、VARCHAR 字段因字符集转换多出空格、FLOAT 因精度差异产生微小误差。
建议对核心表手动抽样比对：
• 取主键连续范围（如 id BETWEEN 1000 AND 1010）；
• 显式列出业务强依赖字段，用 COALESCE 处理 NULL，拼接后算 MD5：SELECT id, MD5(CONCAT(COALESCE(col1,''), COALESCE(col2,''), ...)) AS chk FROM t WHERE id BETWEEN 1000 AND 1010;
• 在新旧库分别执行，逐行比对结果。
这步不能省——很多线上事故都是校验和一致，但金额字段少了一位小数，或者时间戳全错 8 小时。
