如何修复不一致的主从数据？

本文目录导读：

1. 目录导读
2. 为什么要关注主从数据不一致？
3. 常见不一致的根因有哪些？
4. 修复前的准备工作：确认是否需要重置
5. 修复方案一：跳过错误事务
6. 修复方案二：使用pt-table-checksum与pt-table-sync
7. 修复方案三：重建从库
8. 修复后的持续监控与预防
9. 常见问答

主从数据不一致？从原因诊断到修复策略的完整指南

目录导读

• 为什么要关注主从数据不一致？ – 问题背景与影响分析
• 常见不一致的根因有哪些？ – 网络、复制线程、人为操作等分类
• 修复前的准备工作：确认是否需要重置 – 数据比对与风险评估
• 修复方案一：跳过错误事务 – 适用于部分临时性错误
• 修复方案二：使用pt-table-checksum与pt-table-sync – 自动化工具批量修复
• 修复方案三：重建从库 – 最彻底的兜底方法
• 修复后的持续监控与预防 – 如何避免问题再次发生
• 常见问答 – 针对高频问题的专业解答

---

为什么要关注主从数据不一致？

在现代数据库架构中,主从复制是保障高可用性和读写分离的核心手段，当主库与从库之间的数据出现分歧时，轻则导致报表数据不准、业务查询结果异常，重则引发数据错乱、切换后服务不可用，甚至造成永久性数据丢失。不一致的主从数据，本质上是系统可靠性的一颗定时炸弹。

根据实际运维经验,不一致的发生往往具备隐蔽性和累积性，很多时候，从库能正常复制SQL线程，但数据已经悄悄偏差，如果不主动检测与修复，问题可能在数月后才会暴露。

常见不一致的根因有哪些？

诊断修复前,先要搞清楚“为什么会不一致”，常见原因可分为以下几类：

1. 网络抖动或超时 – 主库发送binlog时部分事件丢失，从库未能完整接收。
2. 从库重放错误 – 如唯一键冲突、表结构不一致、外键约束失败等，导致SQL线程停摆。
3. 主从版本差异 – 不同版本对SQL解释或数据类型处理不同，导致结果不一致。
4. 人为误操作 – 直接在从库上执行写入或DDL，破坏复制一致性。
5. 半同步复制超时退化为异步 – 在压力高峰时，主库可能降级为异步复制，丢失部分事务。

实例：某电商平台在大促期间，从库因磁盘IO瓶颈导致relay log写入延迟，恰逢主库切换，恢复后发现订单表缺失部分记录，最终通过全表比对补全了数据。

修复前的准备工作：确认是否需要重置

在动手修复前,必须回答两个关键问题：

• 不一致的范围有多大？ 是单表少数行，还是整个库结构错乱？
• 业务能否接受短暂写停？ 修复过程可能需要锁表或停止应用写入。

建议执行以下步骤：

1. 运行 SHOW SLAVE STATUS\G 查看 Seconds_Behind_Master 和 Last_IO_Error / Last_SQL_Error。
2. 手动比对关键表数据 – 使用 CHECKSUM TABLE 或 pt-table-checksum。
3. 评估修复风险 – 如果差异行数少于总行数的0.1%，优先选择在线修复；如果差异巨大，直接重建从库更稳妥。

经验法则：修复前必须先备份从库当前数据，并确保网络稳定。

修复方案一：跳过错误事务

此方案适用于从库因特定错误SQL线程停住，且该错误事务对业务无害的情况。

步骤：

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

但此方法存在明显缺陷：它会跳过整条事务，可能导致更多数据失配，更推荐的方式是直接找到出问题的binlog位置，手动补全差异后再启动。

适用场景：主从结构完全一致，仅因一条重复主键或临时字段缺失导致复制中断。

修复方案二：使用pt-table-checksum与pt-table-sync

这是目前最主流、最安全的在线修复方式，来自Percona Toolkit，它能在不停机的情况下完成比对与修复。

基本流程：

1. 在主库安装Percona Toolkit，推荐版本3.x以上。
2. 执行校验：

   pt-table-checksum --host=主库IP --user=root --password=xxx --databases=yourdb --tables=yourtable

   它会生成一张 percona.checksums 表，记录每块数据的差值。

3. 生成修复SQL：

   pt-table-sync --print --sync-to-master h=从库IP,u=root,p=xxx --databases=yourdb

   --print 只打印修复语句，不实际执行。

4. 确认无误后执行修复：

   pt-table-sync --execute --sync-to-master h=从库IP,u=root,p=xxx --databases=yourdb

注意事项：

• 建议在业务低峰期执行。
• 如果表数据量极大,可以分批次校验，--chunk-size=2000。
• 修复过程中,从库的同步延迟可能会短暂上升，属于正常现象。

修复方案三：重建从库

当不一致范围广、且无法通过在线工具修复时，重建从库是最彻底的办法。

步骤：

1. 在主库上执行 FLUSH TABLES WITH READ LOCK（短暂阻止写操作）。
2. 使用 mysqldump 或 xtrabackup 创建全量备份，同时记录当前binlog文件名与位置（SHOW MASTER STATUS）。
3. 将备份导入从库。
4. 重置并配置从库复制：

   STOP SLAVE;
   RESET SLAVE ALL;
   CHANGE MASTER TO MASTER_LOG_FILE='binlog.xxx', MASTER_LOG_POS=nnn;
   START SLAVE;

5. 验证： 运行 SHOW SLAVE STATUS，确保 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且 Seconds_Behind_Master 逐渐归零。

优势： 数据一致性有保障，无残留风险。
劣势： 需要锁定主库或使用事务备份，对在线业务存在一定影响，推荐配合 xtrabackup 的流式备份功能，可实现接近零锁定。

修复后的持续监控与预防

修复完成不代表万无一失,想避免再次出现不一致，必须建立以下机制：

1. 定期运行 pt-table-checksum – 建议每日在低峰期执行一次，输出到日志并报警。
2. 开启半同步复制 – 设置 rpl_semi_sync_master_enabled=1 和 rpl_semi_sync_slave_enabled=1，降低异步丢失概率。
3. 设置复制延迟告警 – 当 Seconds_Behind_Master 超过30秒时触发通知。
4. 禁止直接修改从库 – 从库应严格设为 read_only=1，并对super权限做限制。
5. 统一主从版本与字符集 – 避免因版本差异导致的repair错误。

常见问答

Q1: 我的从库 Last_SQL_Error 显示“无法添加外键约束”，如何快速处理？

A: 首先检查从库的表结构与主库是否一致，如果不一致，可以手动在从库上执行对应的DDL，START SLAVE，如果无法人工补全，最安全的方式是重建该表或整个从库。

Q2: pt-table-sync 修复时会不会对主库造成性能冲击？

A: 大概率不会，工具按块扫描，每次只处理少量数据，但如果你在业务高峰运行，建议设置 --chunk-size=500 并降低 --sleep 值，监控主库的QPS与binlog增长量。

Q3: 主从复制已断开24小时，还能通过pt-table-sync修复吗？

A: 可以，但需要确保从库的relay log尚未过期（通过 relay_log_purge 和 relay_log_space_limit 控制），如果relay log已被清理，则需要重建从库，建议先用 pt-table-checksum 评估差异规模，再决定方法。

Q4: 修复完成后如何验证一致性？

A: 再次运行 pt-table-checksum，并检查 percona.checksums 表中的 this_crc 与 master_crc 是否完全一致，如果一致，说明修复成功。

---

修复不一致的主从数据，关键是“快、准、稳”，快在发现，准在诊断，稳在执行。 不要等到业务反馈异常才动手，而是通过自动化工具和监控体系，将不一致消灭在萌芽阶段，每一次修复后，都应该复盘根因，优化复制链路架构，这样才能真正摆脱被动救火的局面。