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 返回空，并不是“一致”，而是复制中断、被过滤、或表根本没有同步过去——此时校验本身已失效，必须先解决复制问题，再重新运行。
