pt-table-checksum 报错“cannot connect to dsn”主因是dsn格式错误或mysql用户无远程权限；须显式用--dsn h=ip,u=user,p=pass指定，且checksum_user需有replication client、process、select权限，并确保主库skip-name-resolve开启时dsn中h=必须为ip。
pt-table-checksum 报错 Cannot connect to DSN 怎么连上主库
根本原因通常是 DSN（Data Source Name）格式写错，或者 MySQL 用户没开远程权限。pt-table-checksum 默认用 --host 和 --user 拼接 DSN，但不支持带密码的短格式（比如 -p123），容易静默失败。
- 必须显式写全 DSN：用
--dsn h=10.0.1.10,u=checksum_user,p=xxx，不能只写--host+--password -
checksum_user需有REPLICATION CLIENT、PROCESS、SELECT权限，且能从从库 IP 连主库（检查SHOW GRANTS FOR 'checksum_user'@'%'） - 如果主库开了
skip-name-resolve，DSN 里的h=必须是 IP，不能是主机名，否则连接超时无提示
校验时从库卡住不动，CPU 很低但进度停在某张表
这是典型锁等待或事务阻塞——pt-table-checksum 默认会在主库加 READ LOCK 或用 START TRANSACTION WITH CONSISTENT SNAPSHOT，若从库正执行大事务（如 ALTER TABLE、长查询），checksum 会一直等 Seconds_Behind_Master 归零才继续。
- 先查从库：运行
SHOW PROCESSLIST，找State是Waiting for table metadata lock或executing且Time> 60 的线程 - 临时解法：在从库执行
KILL [id]干掉阻塞事务（注意别杀复制线程） - 长期避免：校验前用
pt-heartbeat确认延迟 --chunk-size=1000 --max-load="Threads_running=20" 降低压力
输出里出现 Differences on db1.table_a 但 pt-table-sync 同步后仍不一致
说明 checksum 发现了差异，但 sync 工具可能跳过了修复——常见于主从结构异常（比如从库被手动写入、GTID mode 不一致）或 sync 参数没配对。
- 必须确认主从 binlog 格式一致：
SELECT @@binlog_format在主从上都得是ROW；如果是MIXED或STATEMENT，checksum 结果不可靠 - sync 命令要加
--sync-to-master（针对从库校验场景），且必须指定--replicate表名和--dry-run先看 SQL - 如果从库有
read_only=0且被误写，sync 生成的 SQL 会把主库数据覆盖过去，但实际主从 GTID 位置已乱，后续同步可能中断
为什么校验完发现几十张表不一致，但 SHOW SLAVE STATUS 显示 Seconds_Behind_Master: 0
因为 Seconds_Behind_Master = 0 只表示 IO/SQL 线程没积压，不代表数据逻辑一致。主从不一致常发生在：INSERT ... ON DUPLICATE KEY UPDATE 主从执行顺序不同、UUID() 或 NOW() 函数值不同、主库用 SET sql_log_bin=0 跳过记录。
- pt-table-checksum 的
--replicate表（默认percona.checksums）存的是每块分片的 CRC32 值，只要有一行计算结果不同就标为差异，比肉眼比对更敏感 - 如果业务允许小范围误差，可加
--chunk-index指定主键索引（避免走错索引导致分块错位），或用--algorithms=FNV1A_64替代默认 CRC32（略快，碰撞率稍高） - 真正麻烦的是“差异存在但无法定位哪几行”——这时得用
pt-table-sync --print输出 SQL，再人工抽样比对 WHERE 条件
checksum 本身不修数据，它只回答“有没有不一致”；而修不修、怎么修、修完会不会引发新问题，得看主从拓扑是否干净、binlog 是否完整、以及你敢不敢让 sync 直接执行那几万条 UPDATE。
