pt-table-sync不能直接执行--execute修复,因其仅修复数据不一致,不创建库表、不同步结构,需确保源目标表结构完全一致、数据库已存在、账号具备REPLICATION CLIENT及读写权限,且MySQL 5.7下须检查read_only=0、binlog_format=ROW及主键/唯一索引完备性。

pt-table-sync 是唯一能直接修复主从数据不一致的 Percona 工具,但它不是“一键同步”,而是基于 pt-table-checksum 的校验结果或手动指定源/目标后执行差异修复。它不创建表、不建库、不处理权限——这些必须提前准备好。
为什么不能直接跑 pt-table-sync --execute 就完事?
常见错误现象是报错:DBD::mysql::db do failed: Table 'test.t1' doesn't exist on host 192.168.0.103 或 Access denied; you need (at least one of) the SUPER privilege(s)。
根本原因在于:pt-table-sync 默认只比对和修复已有表的数据,不会自动建表、补字段、同步结构。它假设源和目标的表结构完全一致(包括索引、字符集、引擎),且数据库已存在。
- 目标库缺失表?先
mysqldump -d导出源表结构,再mysql导入到目标库 - 目标库有同名表但结构不同?
pt-table-sync会跳过该表,或在 checksum 阶段就失败 - 账号没
SUPER权限?它需要REPLICATION CLIENT查复制状态,SELECT/INSERT/UPDATE/DELETE操作数据,某些模式下还要LOCK TABLES - 用了
--replicate模式但没提前运行pt-table-checksum?那它根本不知道哪些行不一致
pt-table-sync 的两种典型用法及参数取舍
你得先明确:是要“让从库严格等于主库”,还是“只修复已知不一致的表”?前者用 DSN 对比模式,后者依赖 checksum 表。
- DSN 对比模式(最常用):
pt-table-sync --execute h=192.168.0.101,u=root,p=xxx h=192.168.0.103,u=root,p=xxx。前面是源(主),后面是目标(从)。它会逐表对比主键或唯一索引列的哈希值,生成REPLACE INTO或DELETE语句修复。注意:必须确保两个实例都能被同一账号访问,且网络互通 - Checksum 模式(更安全):先在主库运行
pt-table-checksum --nocheck-replication-filters --databases=testdb --replicate=testdb.checksums --create-replicate-table ...,再在从库查SELECT * FROM testdb.checksums WHERE this_crc != master_crc确认不一致表,最后用pt-table-sync --replicate=testdb.checksums --sync-to-master ...让工具自动读 checksum 表执行修复。这种方式避免全表扫描,也绕过了部分权限限制 - 关键参数避坑:
--ignore-databases=mysql,information_schema必加,否则可能误操作系统库;--chunk-size默认太小(如 1000 行),大表建议设为100000减少连接次数;--dry-run和--print务必先跑一遍,看生成的 SQL 是否符合预期
MySQL 5.7 下必须检查的三个兼容性点
MySQL 5.7 默认启用 sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,而 pt-table-sync 生成的修复语句可能触发严格模式报错,导致同步中断。
- 从库是否开了
read_only=1?如果开了,--execute会失败,必须临时关掉:SET GLOBAL read_only = 0(操作完记得恢复) - binlog_format 是否为
ROW?不是的话,pt-table-sync在从库执行的REPLACE不会被复制,造成二次不一致。检查:SELECT @@binlog_format,非 ROW 则需在 my.cnf 中配置并重启 - 表是否有有效主键或唯一索引?没有的话,
pt-table-sync会拒绝操作(报错No good index for table)。它靠索引分块和定位差异行,无索引=无法工作
pt-table-sync 不是黑盒同步器,它的“快速”建立在前提完备之上:结构一致、权限到位、模式兼容、索引健全。最容易被忽略的是 read_only 和 binlog_format 这两个 MySQL 5.7 默认配置,它们会让工具静默失败或产生不可逆偏差。


















