大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

有一次对账，两边总额差了一笔。我先怀疑是数据出错，翻了半天流水，主库那笔是好端端的。问题不在主库，在从库：同一个订单号，从库读出来的状态，跟主库写进去的不是一回事。奇怪的是，主从延迟曲线一直很平，`SHOW SLAVE STATUS` 也没报错。延迟没红，数据却早就对不上了。我盯了那么久的那个指标，根本没看住这件事。

后面我才搞懂，「同步得上」和「数据对得上」，本来就是两回事。前者是性能，后者是正确性。延迟正常，不代表数据一样。今天这篇就把我在这上面踩过的坑分享出来，希望帮你少走弯路少踩坑。

## 不一致从哪来

知道了它会发生，接下来就得问：好端端的复制，怎么会跑歪。主从不一致，常见四个源头。

第一类，非确定性语句。STATEMENT 格式存的是 SQL 原文。从库要把它重放一遍，函数就在从库上重新求值。`UUID()`、`RAND()` 每次结果都不同，主从自然不一样。最容易被误会的是 `SYSDATE()`。很多人以为它跟 `NOW()` 一样。其实 `NOW()` 会被 binlog 里的 `SET TIMESTAMP` 固定住，重放时值一致。`SYSDATE()` 不认这个，取的是从库的真实时间，主从就会差。还有 `LIMIT` 不带 `ORDER BY`，取哪几行全凭引擎顺序，主从各取各的。

第二类，GTID 空洞。复制报错时，为了尽快恢复，很多人会用 `sql_slave_skip_counter` 跳过那笔事务。跳过的代价，是从库的 GTID 集合里少了一条，数据永远缺着。它的隐蔽在于，跳完之后复制继续跑，`SHOW SLAVE STATUS` 一切正常。如果你不去比对数据，根本不知道会少了这一笔。

第三类，并行复制冲突。MySQL 开了多线程复制（`slave_parallel_workers > 0`），主库提交的一组事务，从库按依赖关系并行回放。顺序一旦和主库不一样，比如两笔交易交叉写了同一行，从库的 SQL 线程就会停住报错。常见的是 1062（Duplicate entry）和 1032（Cannot find record），背后多半就是回放顺序对不上。5.7 的 LOGICAL_CLOCK 和 8.0 的 WRITESET 都在改善，但冲突窗口没法完全关死。

第四类，手工改从库。从库没开 `super_read_only`，有人上去直接改数据。改完复制继续跑，没人报警。

## 校验：pt-table-checksum 怎么用

四个源头，有的能提前防，有的只能事后抓。但不管你怀疑哪一个，第一步都一样，先确认到底哪里不一致。我用的工具是 pt-table-checksum，Percona Toolkit 里的分片校验工具。

它的工作原理是这样的。工具连上主库，把每张表切成若干 chunk，对每个 chunk 计算 CRC32 校验和。这个校验和通过 binlog 复制到从库，从库也存一份同样的结果。然后工具去从库查那份校验表，把主库和从库的 CRC 逐 chunk 对比。不一样的那个 chunk，就是数据不一样的地方。

```bash
# 在主库上跑，把结果写进 percona.checksums 表
pt-table-checksum \
  --replicate=percona.checksums \
  --databases=app \
  --chunk-size=1000 \
  --sleep=0.1 \
  h=master_host,u=checksum_user,p=xxx
```

两个参数要盯紧。`--chunk-size` 是每次校验的行数，太大拖库，太小切太多片。一般一千到五千，看表大小。`--sleep` 是每次 chunk 之间的间隔秒数，给主库喘口气。别在高峰跑，或者 `--sleep` 设大点。

还有一个自动限流的参数，`--max-load`，很容易被漏掉。它盯的是活跃线程数（`Threads_running`），默认超过 25 就自动暂停，等压力降下来再接着跑。这才是真正的兜底——前面两个参数是你自己估出来的，它是盯着主库的实时水位动态刹车。

跑完之后，它会给一份输出。关键看 `DIFFS` 列。

```
         TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
10-15T14:20:00      0      1  2345678         0     234       0  123.4 app.t_order
10-15T14:20:05      0      0   123456         0      12       0   5.6 app.t_user
```

（输出格式为示意，实机以 Percona Toolkit 实际输出为准。）

`DIFFS` 非零，说明这张表的至少一个 chunk 在主从两边不一致。上面 `t_order` 的 `DIFFS = 1`，就是不一致。

这里有个前提别忘了。校验和是先在主库算好，再靠 binlog 传到从库去比对的。也就是说，复制本身得是通的。要是复制已经停了、卡着，工具拿到的比对也会失真。所以别拿校验去判断复制通不通，那个因果是反的。

## 定位：从差异到具体行

知道哪张表有问题了，下一步是找具体差在哪。去从库查校验表。

```sql
-- 从库上查：哪些 chunk 的 CRC 对不上
SELECT db, tbl, chunk, master_cnt, this_cnt, master_crc, this_crc
FROM percona.checksums
WHERE master_crc <> this_crc
  AND this_crc IS NOT NULL;
```

拿到 `db`、`tbl`、`chunk` 之后，就知道是哪块分片出了问题。要看到底差哪行，有两种办法。一是把主从两边的这个 chunk 分别导出来 diff。二是用 pt-table-sync 加 `--print` 预览，看它打算生成哪些 corrective 语句。

```bash
# pt-table-sync 预览：它会输出在主库上执行的 corrective SQL
pt-table-sync \
  --print \
  --replicate=percona.checksums \
  h=master_host,u=sync_user,p=xxx \
  h=replica_host,u=sync_user,p=xxx
```

**注意**：`--print` 只打印，不执行。先看清它要改什么，再决定下一步。

## 修复：pt-table-sync 的安全边界

pt-table-sync 能自动把从库拉回和主库一致。但它是个危险操作，用错了会雪上加霜。

```bash
# 确认无误后执行修复（必须在主库上跑，变更通过 binlog 传播到从库）
pt-table-sync \
  --execute \
  --replicate=percona.checksums \
  h=master_host,u=sync_user,p=xxx \
  h=replica_host,u=sync_user,p=xxx
```

三条安全线，一条都不能省。

第一，执行前必做备份。不管是 `mysqldump` 还是物理快照，先把当前状态留底。万一修错了，能退回去。

第二，必须在主库上跑，变更通过 binlog 正常复制到从库。如果直接连从库跑，变更不复制，两边又会差。

第三，别在高峰期盲目 sync。它会生成大量的 UPDATE / INSERT / DELETE，吃 IO，也吃复制带宽。选低峰窗口跑。

## 预防：别等出事再查

修复只是止血，预防才是根治。

`binlog_format=ROW`，MySQL 5.7 起默认就是 ROW，但老库还是 STATEMENT 或 MIXED 的，尽早切。ROW 格式存的是行级变更，不依赖函数重算，能挡掉大部分非确定性语句的问题。

`super_read_only=1`，从库开只读。注意 `read_only` 挡不住有 SUPER 权限的用户，要开到 `super_read_only`。业务账号本身没写权限，从库再锁一层，基本杜绝手工改从库。

定期跑 checksum 校验。不是出了事才跑，是当成周常或月常任务。设个 cron，低峰自动跑，结果进告警。不一致要能在监控里先看见，不是靠用户投诉才发现。

GTID + 变更管控。开了 GTID 后，别再用 `sql_slave_skip_counter` 跳过事务。遇到需要跳的场景，先分析原因、留档、再操作。每次 GTID 操作都要记录，留痕可追溯。

## 同步得上，不等于对得上

主从健康，从来不是一条延迟曲线能说清的。延迟正常，只说明从库在追，还追得挺快。它一个字都没保证，追到的东西对不对。同步得上是性能，对得上才是正确性。性能能靠监控盯，正确性只能靠校验换。你省掉的那次 checksum，不会消失。它只是变成某天对不上、又查不出从哪来的那笔账。

## 避坑清单

想少欠几笔这样的账，日常把这几点盯牢。

非确定性语句是主从不一致的常见源头。`NOW()`、`UUID()`、`RAND()` 在 STATEMENT 格式下各算各的，业务 SQL 要尽量确定性，或确保用 ROW 格式。`LIMIT` 不带 `ORDER BY` 也是坑。

校验要在低峰跑，并且限流。`pt-table-checksum` 不轻，`--chunk-size`、`--sleep`、`--max-load` 设好了再跑，别把主库拖垮。

最后一条是我自己踩的。我有一次跑 `pt-table-sync --execute`，没先备份也没用 `--print` 预览，结果一行数据的修复把关联表也带歪了。那次之后我定了条死规矩：sync 之前先 `--print`，`--print` 之后先备份，备份完才 `--execute`。多花十分钟，少救一次火。

## 写在最后

主从数据不一致，最难的不是修，是它发生了你却不知道。延迟曲线太好看，反而让人放松警惕。数据不像延迟会喊疼，它只会安安静静地，主库存一份，从库存一份，各是各的。

定期校验、从库只读、binlog 用 ROW、GTID 操作留痕，这几条听着老生常谈。可每一条，都是真踩过之后才肯老老实实补上的。复制能跑不稀奇，跑得对才值钱。

你们的主从校验是怎么跑的？多久一次，用的什么工具？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


有一次对账，两边总额差了一笔。我先怀疑是数据出错，翻了半天流水，主库那笔是好端端的。问题不在主库，在从库：同一个订单号，从库读出来的状态，跟主库写进去的不是一回事。奇怪的是，主从延迟曲线一直很平，SHOW SLAVE STATUS 也没报错。延迟没红，数据却早就对不上了。我盯了那么久的那个指标，根本没看住这件事。

MySQL主从数据不一致排查：从checksum到修复的安全流程

从对账时两边总额对不上、延迟却正常切入，把主从不一致的根因分为四类，讲清 pt-table-checksum 的分片校验、限流与定位，以及 pt-table-sync 的安全修复边界。

人工智能

主从数据不一致的四大源头、校验修复工具链、预防措施。用pt-table-checksum定位差异，pt-table-sync安全修复。核心观点：延迟正常不等于数据一致，定期校验和从库只读才是根本保障。

代码解释

数据库

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL主从数据不一致排查：从checksum到修复的安全流程-腾讯云开发者社区-腾讯云

MySQL主从数据不一致排查：从checksum到修复的安全流程

MySQL主从数据不一致排查：从checksum到修复的安全流程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐