pt-table-sync 不适用于 mysql 5.7 gtid 模式，因其在从库执行的 replace/insert 会生成非法 gtid，触发 error 1782 导致 sql 线程中断；必须关闭 gtid 或改用 pt-table-checksum + --replicate 配合 idempotent 模式修复。
pt-table-sync 不能直接用于 MySQL 5.7 GTID 模式下的主从修复，强行用会破坏复制关系甚至导致从库中断。 它只适合非 GTID 环境，或你明确关闭了 gtid_mode 并用传统 binlog 文件+position 方式同步的场景。
为什么 pt-table-sync 在 MySQL 5.7 GTID 下大概率失败
MySQL 5.7 默认启用 GTID（尤其生产环境），而 pt-table-sync 的核心逻辑是：在从库上执行 REPLACE INTO 或 DELETE + INSERT 来对齐数据。这些语句会生成新的 GTID，但它们不是来自主库 binlog 的合法事务，会导致：
-
Slave_SQL_Running: No，报错ERROR 1782 (HY000): Statement violates GTID consistency - 从库 SQL 线程卡死，
Last_SQL_Error显示 GTID 冲突 - 即使加
--sync-to-master，它仍无法绕过 GTID 的事务来源校验
替代方案：用 pt-table-sync 前必须做的三件事
如果你坚持要用 pt-table-sync（例如确认是单库、无 GTID、或临时停用 GTID 的测试环境），必须先满足：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 主从都关闭 GTID：
SET GLOBAL gtid_mode = OFF_PERMISSIVE;→SET GLOBAL gtid_mode = OFF;，并重启 mysqld（需修改my.cnf中gtid_mode=OFF） - 主库执行
FLUSH LOGS;，确保当前 binlog 是干净起点；从库STOP SLAVE;，再用CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;手动对齐到该位置 - 确认从库没有写入（
read_only=ON已生效），否则pt-table-sync可能误删从库本地数据
更安全的 MySQL 5.7 主备数据修复路径
生产环境推荐以下顺序排查和修复，避免引入新风险：
- 先查错因：
SHOW SLAVE STATUS\G看Last_SQL_Errno和Last_SQL_Error，常见如1032（行不存在）、1062（唯一键冲突）——这类可跳过，加slave_skip_errors=1032,1062后重启 - 若跳过多次仍失败，说明不一致已扩散，应停用从库读流量，改用
mysqldump --single-transaction --set-gtid-purged=OFF全量重导（注意：GTID 模式下必须加--set-gtid-purged=OFF，否则 dump 文件里带的SET @@GLOBAL.GTID_PURGED会覆盖从库已有 GTID） - 真正需要逐行比对的场景（如审计要求），用
pt-table-checksum+pt-table-sync --replicate组合，但前提是主从都处于slave_exec_mode=IDEMPOTENT模式下，且所有表有主键或唯一键
真正麻烦的从来不是工具调用，而是没看清 GTID 是否开启、没确认从库是否被写入、也没验证 pt-table-sync 生成的语句能否被从库 SQL 线程接受——这三个点漏掉任意一个，修复就变成故障。
