用mysqldump或xtrabackup修复主从不一致，必须保证备份时主库一致性并精确记录binlog位点；mysqldump需加--single-transaction、--master-data=2、--set-gtid-purged=off；xtrabackup须用--dump-slave=2提取binlog位置；恢复后须校验数据、sql模式、字符集及时区。
直接说结论：用 mysqldump 或 xtrabackup 备份修复主从不一致，**必须保证备份时主库处于一致性状态，并精确记录 binlog 位点**；否则恢复后主从仍会错位，甚至越修越乱。
mysqldump 恢复前必须加的三个参数
很多人 dump 完就直接 restore，结果发现从库数据还是对不上——问题几乎都出在没控制好“时间快照”和“复制锚点”。
-
--single-transaction：仅对 InnoDB 表生效，靠 MVCC 实现无锁一致性快照；但 MyISAM 表仍可能被并发写破坏，跨引擎必须配合--lock-all-tables -
--master-data=2：在 dump 文件开头插入CHANGE MASTER TO注释，含MASTER_LOG_FILE和MASTER_LOG_POS；缺了它，从库无法准确定位同步起点 -
--set-gtid-purged=OFF（GTID 模式下必需）：避免 dump 文件里写死全局 GTID 集合，导致从库执行时因 GTID 冲突报错ERROR 1840 (HY000)
xtrabackup 恢复时最容易漏掉的 binlog 信息
xtrabackup 热备虽快，但恢复后常忽略一个关键细节：备份完成瞬间的 binlog 位置不是自动写进 backup-my.cnf 或日志文件的，得手动提取。
- 备份完成后，检查输出日志末尾是否有类似
binlog_pos = filename 'mysql-bin.000012', position '123456'的行；没有？说明没启用--slave-info或--dump-slave - 正确做法是加
--dump-slave=2（MySQL 5.6+）或--slave-info（旧版），让 xtrabackup 自动把SHOW SLAVE STATUS中的Exec_Master_Log_Pos写入xtrabackup_slave_info文件 - 恢复后，从库执行
CHANGE MASTER TO ... MASTER_LOG_FILE='...', MASTER_LOG_POS=...时，必须用这个文件里的值，不能凭记忆或猜
恢复后验证是否真一致，别只看 SHOW SLAVE STATUS\G
Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 只代表线程活着，不代表数据对得上。真正要查的是业务层一致性。
- 先跑
SELECT COUNT(*) FROM t1;对比主从——但要注意：如果表有软删字段（如is_deleted=1），COUNT 结果一样也不等于数据一致 - 更可靠的是抽样校验关键字段：比如订单表，执行
SELECT id, user_id, amount, updated_at FROM order WHERE updated_at > '2026-08-01' ORDER BY id LIMIT 100;，主从结果逐行比对 - 如果发现差异，立刻停同步，用
pt-table-checksum定位到具体分块，再用pt-table-sync --print看修复语句逻辑是否安全——别直接--execute
最常被跳过的环节是：恢复后没校验 sql_mode、字符集、时区是否与主库完全一致。哪怕只差一个 STRICT_TRANS_TABLES，INSERT 就可能被截断或拒绝，后续同步直接卡住。这些配置项不写进备份文件，得人工核对。
