MySQL主从数据一致性检查pt-table-checksum使用方法和步骤详解

pt-table-checksum 必须在主库执行——这一点，很多初次接触的人都会踩坑。它并不是“直连从库去比对”，而是借助 binlog 复制将校验逻辑同步过去，由从库本地重新计算，再写入 percona.checksums 表。简单来说，你在主库发送一条类似 REPLACE INTO percona.checksums SELECT ... CRC32(...) FROM ... 的语句，这条语句会被记录到 binlog，从库的 SQL 线程获取后，利用自身数据重新计算 this_crc。如果你强行用 --host=从库IP 直连，很可能卡在 Waiting for replica mysql2 或者直接报错 Cannot connect to host，根本运行不起来。

为什么必须在主库运行，且不能跳过复制链路

工具的设计决定了它必须依赖复制流。它生成的语句形式如 REPLACE INTO percona.checksums SELECT db, tbl, chunk, CRC32(CONCAT(...)), COUNT(*) FROM ... WHERE id BETWEEN ? AND ?，这些语句写入 binlog，被从库 SQL 线程重放。从库并不是被“查询”，而是被动执行相同的逻辑，用自己的数据重新计算 this_crc。因此，绕过复制直接连接从库，相当于让工具失去可验证的基础。

常见的误操作值得多提几句：

• 用 --host=从库IP --user=chkuser 直连从库：工具会尝试在从库上执行 SHOW PROCESSLIST、修改 binlog_format，但权限和配置通常不满足，直接导致挂起。
• 误以为“命令行输出 Diffs = 0 就代表一致”：这只是说明主库没有写入差异记录，并不代表从库的 percona.checksums 表已经同步或内容正确。
• 忽略了 replicate_ignore_db=percona：这样从库根本没有收到 percona.checksums 的变更，表为空，自然无法比对出差异。

执行前必须确认的三件事（缺一不可）

否则结果无效，或工具启动即失败：

• Seconds_Behind_Master = 0，且 Slave_IO_Running = Yes、Slave_SQL_Running = Yes（使用 SHOW SLAVE STATUS\G 确认）。
• 主库已显式配置 report_host 和 report_port（SHOW SLAVE HOSTS 已废弃，不能依赖）。
• 校验账号（如 chkuser）已在每个从库执行授权：GRANT SELECT, REPLICATION CLIENT ON *.* TO 'chkuser'@'%'；MySQL 8.0+ 还需确认认证插件兼容，老版本 pt-table-checksum（如 3.1.x）不支持 caching_sha2_password。

关键参数怎么设才不踩坑

默认参数在生产环境基本不可用。以下组合是经过验证的最小安全集：

• --replicate=percona.checksums：指定校验结果写入哪张表，确保该表在所有从库存在且结构一致。
• --recursion-method=dsn=D=percona,t=dsns：避免自动发现失败，提前在主库建好 percona.dsns 表，填入各从库 host/user/port。
• --no-check-binlog-format：绕过 ROW 模式下对 binlog_format 的检查（MySQL 5.7+ 默认 ROW，但旧版工具仍会报错）。
• --max-lag=1：从库延迟超过 1 秒自动暂停，防止校验“追着延迟跑”。
• --chunk-size=1000：大字段或慢索引容易触发 Skipped，调高可减少跳过，但不要设得太大（如 50000），否则单块锁表时间过长。

示例命令：

pt-table-checksum --host=192.168.10.100 --user=chkuser --password='xxx' --databases=myapp --replicate=percona.checksums --no-check-binlog-format --recursion-method=dsn=D=percona,t=dsns --max-lag=1 --chunk-size=1000

怎么看结果才算真正一致？别信命令行输出

执行完成后，登录从库查询才是唯一可信的依据：

• 在从库执行：SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_bad = 1
• 若返回空结果，才说明当前校验范围内的数据一致。
• 若返回记录，重点关注 db、tbl、chunk 字段，配合 pt-table-sync --sync-to-master 定位并修复。

容易被忽略的点：如果从库上 SELECT * FROM percona.checksums 返回空，并不是“一致”，而是复制中断、被过滤、或表根本没有同步过去——此时校验本身已失效，必须先解决复制问题，再重新运行。