怎样使用Percona Toolkit检测MySQL备份恢复后主从表数据一致性-mysql教程-PHP中文网

唯一可靠路径是在主库运行pt-table-checksum写入percona.checksums表，依赖复制同步到从库比对；在从库直接执行会因权限、复制状态或变量问题失败。

怎样使用percona toolkit检测mysql备份恢复后主从表数据一致性

直接在主库上运行 pt-table-checksum，结果写入 percona.checksums 表，靠复制机制自动同步到从库比对——这是唯一可靠路径。备份恢复后若跳过这步，你根本不知道从库哪张表、哪几行数据已“静默损坏”。

为什么不能在从库上直接跑 `pt-table-checksum`

工具设计依赖主从复制链路：它在主库生成校验 SQL（如 REPLACE INTO ... SELECT CRC32(...) FROM t1 WHERE id BETWEEN ? AND ?），再靠 binlog 把这条语句“推”到从库执行并重算一次校验和。如果你把 --host 指向从库，它会尝试在从库上模拟主库行为（比如改 binlog_format、查 SHOW PROCESSLIST 找 slave），但权限缺失、复制状态异常或变量不可写，大概率卡死或报错：Cannot connect to host 或 Replica mysql2 is stopped. Waiting.。

备份恢复后常见陷阱：

从库的 Slave_IO_Running 和 Slave_SQL_Running 看似为 Yes，但 Seconds_Behind_Master 可能是 NULL（IO 线程假活）或远超预期；
恢复时用了 mysqldump --single-transaction，但没加 --master-data=2，导致从库起始位点错误，后续所有校验都无效；
备份文件里含 SET SQL_LOG_BIN=0，恢复时跳过了 binlog，percona.checksums 表压根没同步过去。

`pt-table-checksum` 必须满足的硬性前提

备份恢复完成后，别急着跑命令，先确认这五件事：

主库账号有完整权限：SELECT, INSERT, UPDATE, REPLICATION SLAVE, PROCESS, SUPER；
主库已存在 percona 库：CREATE DATABASE IF NOT EXISTS percona;；
所有待校验表都有主键或非空唯一索引（否则跳过，输出 No good index）；
主库 binlog_format 是 ROW 时，必须加 --no-check-binlog-format，否则直接退出；
从库延迟不能长期卡在阈值外——默认 --max-delay=1 秒，备份刚恢复完常有几十秒延迟，建议临时放宽：--max-delay=60。

执行校验时的关键参数与避坑点

基础命令示例（主库执行）：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

pt-table-checksum \
  --replicate=percona.checksums \
  --no-check-binlog-format \
  --no-check-replication-filters \
  --max-delay=60 \
  --databases=myapp_db \
  h=192.168.5.100,u=chk,p=secret

重点说明：

--replicate=percona.checksums：必须显式指定，不能依赖默认值——有些环境默认库名不是 percona；
--no-check-replication-filters：备份恢复后常启用了 replicate-do-db 类过滤，不加这个参数会漏检被过滤的库；
不要用 --replicate-check-only 预览——它只查 percona.checksums 表中已有记录，而备份恢复后该表为空，结果永远显示“0 diffs”；
校验过程会给表加 S 锁（共享锁），大表可能阻塞 UPDATE/DELETE，观察 SHOW PROCESSLIST 中是否有长时间 Waiting for table level lock；
输出里看 DIFFS 列是否为非零值，忽略 TS（时间戳）和 ROWS（行数）——它们只反映校验进度，不表征一致性。

如何快速定位备份恢复后的真实不一致块

校验命令跑完后，立刻连从库查：

SELECT db, tbl, chunk, lower_boundary, upper_boundary, this_crc, master_crc, DIFFS 
FROM percona.checksums 
WHERE (master_crc IS NULL AND this_crc IS NOT NULL) 
   OR (master_crc IS NOT NULL AND this_crc IS NULL) 
   OR (master_crc != this_crc) 
   OR DIFFS != 0;

注意两个易忽略点：

如果某块的 master_crc 为 NULL，说明主库没成功写入该校验和（可能是权限不足或表结构变更导致分块失败），不能简单认为“从库多了一行”，得回主库查日志；
备份恢复后若从库 relay_log 被清空过，percona.checksums 表虽已同步，但部分块的校验 SQL 可能因 relay 日志缺失而未执行——此时需手动检查 SHOW SLAVE STATUS 的 Relay_Log_File 和 Relay_Log_Pos 是否连续。

最麻烦的情况是：校验结果显示一致，但业务查询仍出错。这时候问题往往不在数据本身，而在备份时未导出函数、视图或触发器定义，或者从库字符集与主库不一致（如主库 utf8mb4_0900_as_cs，从库仍是 utf8mb4_general_ci）——校验工具完全不检查这些元数据。