主从架构定时数据一致性巡检需将pt-table-checksum变为可重复、可监控、可告警的自动化任务，核心是环境固化、参数可控、结果校验及配套告警；必须确保从库延迟为0、权限完备、表结构一致，并用指定参数定时执行，结果须查percona.checksums表而非命令输出，再通过脚本退出码接入监控与告警。
主从架构下做定时数据一致性巡检，核心是把 pt-table-checksum 变成可重复、可监控、可告警的自动化任务，而不是每次手动跑一次命令。关键不在“能不能跑”，而在“跑得稳不稳、结果看得清不清、异常抓得准不准”。
巡检前必须固化的基础环境
定时任务一旦启动，就无法人工干预，所以环境必须一次配稳：
- 所有从库 Seconds_Behind_Master = 0，且
Slave_IO_Running和Slave_SQL_Running都为Yes - 主库显式配置
report_host和report_port（不能依赖已废弃的SHOW SLAVE HOSTS） - 校验账号（如
chkuser）在每个从库上具备SELECT和REPLICATION CLIENT权限，并执行FLUSH PRIVILEGES -
percona.checksums表已在所有节点存在、结构一致、可写（首次运行加--create-replicate-table）
定时执行命令要带可控参数
避免默认行为导致漏检或误跳，推荐用以下固定模板写入 crontab：
0 2 * * 1 pt-table-checksum --host=192.168.10.100 --user=chkuser --password='xxx' --databases=myapp --replicate=percona.checksums --no-check-binlog-format --recursion-method=dsn=D=percona,t=dsns --max-lag=1 --chunk-time=0.5 --quiet
-
--recursion-method=dsn：从主库percona.dsns表读取从库列表，避免自动发现失效 -
--max-lag=1：从库延迟超 1 秒自动暂停，防止校验“追着延迟跑” -
--chunk-time=0.5：控制每块处理时间，兼顾速度与业务影响 -
--quiet：减少日志噪音，便于后续解析输出
结果验证不能只看命令行输出
Diffs = 0 是假象，真正结果写在 percona.checksums 表里。定时任务执行完后，必须立即查表确认：
SELECT db, tbl, chunk, master_cnt, this_cnt, master_crc, this_crc FROM percona.checksums WHERE master_cnt != this_cnt OR master_crc != this_crc;
- 返回空结果 → 当前校验范围内数据一致
-
master_cnt > 0 AND this_cnt = 0→ 复制中断，从库缺失整块数据 -
master_cnt = 0 AND this_cnt > 0→ 从库有额外数据（如误写、过滤规则异常）
配套监控和告警机制
光跑命令不够，得让系统自己“说话”：
- 用脚本封装执行 + 查询逻辑，成功返回 0，发现差异返回 1
- 将退出码接入监控系统（如 Zabbix、Prometheus + node_exporter 自定义指标）
- 配置企业微信/钉钉机器人，当查询到差异时，推送具体表名、chunk 范围、偏差类型
- 保留最近 7 天的
percona.checksums历史快照（如每天凌晨备份一次），便于追溯变化趋势
