MySQL主从数据不一致如何自动修复_利用pt-table-checksum校验

pt-table-checksum连不上从库主因是默认用主库账号连从库且依赖processlist查从库线程；Differences=1但pt-table-sync不修复因默认--dry-run；大表慢因CRC计算与chunk划分低效；延迟高时误报因读取旧checksum结果。pt-table-checksum 连不上从库报错 Cannot connect to slave根本原因不是网络不通，而是 pt-table-checksum 默认用主库账号去连从库，但很多环境从库只开了复制账号（如 repl@%），没给校验账号权限。它还会默认尝试用 --recursion-method=processlist 去查从库线程，如果从库禁用了 PROCESS 权限或关闭了 performance_schema，就会直接失败。实操建议：显式指定从库连接参数：--slave-host=192.168.1.102 --slave-user=checksum_user --slave-password=xxx确保该账号在从库有 SELECT + REPLICATION CLIENT 权限（REPLICATION CLIENT 是为了查 SHOW SLAVE STATUS）禁用自动发现，强制走 DNS 或指定 IP：--recursion-method=dsn=h=192.168.1.102,P=3306,u=checksum_user,p=xxx别依赖 processlist——主库 SHOW PROCESSLIST 里看不到从库线程信息，这个方法在跨机房或代理后基本不可靠校验结果里 Differences 列全是 1，但 pt-table-sync 却不修复这是因为 pt-table-checksum 只负责“发现差异”，而 pt-table-sync 默认是只打印 SQL，不执行——它默认加了 --dry-run。很多人跑完 checksum 就以为万事大吉，其实 sync 根本没动数据。实操建议：必须显式加 --execute 才会真正同步：pt-table-sync --execute --sync-to-master h=192.168.1.102,u=checksum_user,p=xxx D=test,t=user务必先用 --print 看生成的 SQL 是否合理，尤其注意 WHERE 条件是否覆盖全表、有没有触发主键冲突避免在业务高峰跑 --execute：它会按 chunk 分批 DELETE + REPLACE，锁表时间虽短，但高并发下可能堆积成锁等待如果从库有唯一键冲突（比如主库 INSERT 后又删了，从库还留着），pt-table-sync 会跳过该 chunk 并报错 DBD::mysql::st execute failed: Duplicate entry，得人工介入为什么 pt-table-checksum 在大表上跑得慢甚至卡住核心瓶颈不在网络，而在 MySQL 自身：它默认对每张表做 CRC32(CONCAT(...))，字段越多、值越长、NULL 越多，计算越慢；更关键的是，它依赖 SELECT ... INTO OUTFILE 或临时表分 chunk，如果表没主键或主键不是整型，chunk 划分会退化成全表扫描。 Tellers AI Tellers是一款自动视频编辑工具，可以将文本、文章或故事转换为视频。