mysql执行SQL后主从不一致_如何利用pt-table-checksum进行校验-mysql教程-PHP中文网

pt-table-checksum 连不上从库主因是权限、网络或配置不一致，需检查从库只读设置、bind_address、认证插件兼容性，并显式指定--recursion-method=dsn。

mysql执行sql后主从不一致_如何利用pt-table-checksum进行校验

连不上从库是 pt-table-checksum 最常见的卡点，不是权限问题就是网络或配置没对齐。

主库能连，从库连不上？先确认 pt-table-checksum 是用什么账号跑的——它默认尝试用主库的连接参数去连从库，但很多环境从库只开了只读、禁了远程登录，或者 skip_networking=ON
检查从库的 my.cnf 是否设置了 bind_address = 127.0.0.1，导致外部无法访问；临时改 0.0.0.0 或加监听内网 IP
MySQL 8.0+ 默认认证插件是 caching_sha2_password，而老版本 Percona Toolkit 可能不兼容，报错类似 Plugin caching_sha2_password could not be loaded，得在从库创建用户时显式指定 mysql_native_password
命令里别偷懒省 --recursion-method=dsn，尤其当从库不在标准端口或用了非默认 socket 时，必须用 DSN 显式写：--recursion-method="dsn=D=percona,t=dsns"，并提前建好 percona.dsns 表填从库地址

这不是数据真不一致，而是 pt-table-checksum 自身机制和表结构/配置冲突导致的误报。

主从 binlog_format 不一致（比如主是 ROW，从是 MIXED 或 STATEMENT）会导致 checksum SQL 在从库执行失败，跳过校验但标记为 DIFF
从库开了 read_only=ON 但没关 super_read_only，pt-table-checksum 的校验语句会被拒绝，日志里能看到 ERROR 1290 (HY000): The MySQL server is running with the --read-only option
表里有 TIMESTAMP 字段且没设默认值，主从时区不同或 explicit_defaults_for_timestamp=OFF，插入时自动填充时间不一致，checksum 就对不上
用 --chunk-index 指定了非主键索引，而该索引存在重复值或 NULL，分块逻辑错乱，checksum 范围重叠或遗漏

本质是它在主库上“边查边改”，对大表或高负载库非常敏感，不是程序坏了，是资源被压住了。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

默认每 chunk 查 1000 行，但如果你的主键跨度极大（比如自增 ID 中间有大量删除），实际扫描行数可能是几十万，建议加 --chunk-size-limit=2.0 限流
没加 --max-load，一跑起来从库 CPU 突到 100%，复制延迟飙升，工具自己检测到后会休眠甚至退出；推荐设成 --max-load="Threads_running=25"（按你从库常态线程数 ×1.5）
表上有长事务没提交，pt-table-checksum 的 SELECT 会被阻塞，表现为卡在某 chunk 不动；查 SHOW PROCESSLIST 找 State: Sending data + 长时间运行的线程
别在业务高峰跑，更别在从库做备份的同时跑它——两者都会扫表、争 IO 和 buffer pool

pt-table-checksum 只负责“发现”，不负责“修复”；真要修，得靠 pt-table-sync，但它极其危险，一步错就丢数据。

先用 --dry-run 和 --print 看它打算生成什么 SQL，重点核对 WHERE 条件是否精确命中差异行，避免全表覆盖
务必在从库上加 --sync-to-master，而不是反向同步——它默认把从库当源，主库当目标，搞反等于把脏数据刷回主库
如果校验表有外键或触发器，pt-table-sync 生成的 REPLACE/INSERT 可能触发意外行为，建议临时禁用：SET FOREIGN_KEY_CHECKS=0; SET SQL_LOG_BIN=0;
生产环境严禁直接执行 pt-table-sync --execute；应导出 SQL 到文件，人工 review 后再 source，且确保主从复制已停（STOP SLAVE），修完再启