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 默认配置，它们会让工具静默失败或产生不可逆偏差。
