修复MySQL从库数据一致性必须停用旧复制链路并基于主库一致快照重建：先用pt-table-checksum校验行级差异，STOP SLAVE后执行RESET SLAVE ALL清空元数据，再通过FLUSH TABLES WITH READ LOCK+mysqldump --single-transaction --master-data=2导出，导入后依据手动记录的SHOW MASTER STATUS位点配置CHANGE MASTER TO并验证追平。
必须停掉旧复制链路、用主库一致快照重建，不能直接导入 dump 后靠猜位点启动。
先确认漂移是否真实存在
别一看到 Seconds_Behind_Master 非零就重做——它可能只是临时延迟。真正要担心的是数据行级不一致：
- 运行
pt-table-checksum在主库上校验，再查从库的percona.checksums表，看哪些表diff_cnt > 0 - 检查
SHOW SLAVE STATUS\G中的Slave_SQL_Running_State：如果是Reading event from the relay log但Seconds_Behind_Master持续增长，大概率已错位 - 对比主从的
SHOW MASTER STATUS（主）和Master_Log_File+Read_Master_Log_Pos（从），若不匹配，说明 IO 线程拉的日志位置已偏离
STOP SLAVE 后必须用 RESET SLAVE ALL
只执行 STOP SLAVE 不够，残留的 master.info、relay-log.info 和中继日志会干扰新同步：
-
RESET SLAVE ALL（MySQL 5.7+）会清空所有复制元数据，包括 GTID_EXECUTED 和 relay log 文件列表 - 执行后手动检查
/var/lib/mysql/下是否还有relay-bin.*文件残留，有则rm -f（避免START SLAVE时误读旧日志） - 不要用
RESET SLAVE（无ALL），它不清除master.info，重启 mysqld 后可能自动重连旧主库
mysqldump 必须带 --single-transaction 和 --master-data=2
缺一不可，否则 dump 过程中主库写入会导致位点失效：
-
--single-transaction保证 InnoDB 表一致性快照，但对 MyISAM 无效（如有，需加FLUSH TABLES WITH READ LOCK） -
--master-data=2会在 dump 文件开头插入CHANGE MASTER TO注释，含准确MASTER_LOG_FILE和MASTER_LOG_POS - 导出后立刻记录
SHOW MASTER STATUS，因为--master-data=2写入的是 dump 开始时刻的位点，而实际锁表或事务开始时间可能有毫秒级偏差
导入后 CHANGE MASTER TO 不能依赖 dump 文件里的注释
dump 文件里的 CHANGE MASTER TO 是注释，不会自动执行；且如果主库在 dump 后又写了 binlog，该位点已过期：
- 导入完成后，用你手动记录的
SHOW MASTER STATUS结果（不是 dump 里的）执行CHANGE MASTER TO - GTID 模式下改用
CHANGE MASTER TO MASTER_AUTO_POSITION = 1，但前提是主库gtid_mode=ON且 dump 时用了--set-gtid-purged=ON - 启动前检查从库
datadir权限是否正确，mysql用户能否读写，否则START SLAVE会静默失败
最易被忽略的是：全量同步不是“导完就完”，而是要等 SHOW SLAVE STATUS 中 Seconds_Behind_Master 归零、且 Exec_Master_Log_Pos 稳定增长，才算真正追平。中间任何一次 Slave_SQL_Running: No 都意味着数据已再次漂移，得回退排查。
