不能直接用mysqldump+md5sum做异地一致性校验，因高延迟、窄带宽、大数据量导致导出耗时长且业务持续写入，加之mysqldump不保证行序，相同数据哈希值必然不同，误判为不一致。
为什么不能直接用 mysqldump + md5sum 做异地一致性校验
跨地域（比如北京↔法兰克福）的数据库校验，最典型的误区就是把单机房那套“导出再比哈希”的方法照搬过去。延迟高、带宽窄、数据量大——三者叠加会让一次全表 mysqldump 耗时几十分钟甚至数小时，期间业务还在写，结果还没比完，数据又变了。更关键的是，mysqldump 默认不保证顺序，同一张表在两地导出的行序可能不同，md5sum 必然不等，但这不代表数据不一致。
用 pt-table-checksum 时必须关掉 --chunk-index 和启用 --replicate
pt-table-checksum 是 Percona Toolkit 里专为 MySQL 主从/多活场景设计的一致性校验工具，但它默认行为在异地多活下会失效。原因有二：
- 它默认按主键分块（
--chunk-index），但异地多活常有双向同步、LWW 冲突消解逻辑，主键可能被重写或跳过，导致分块边界不一致 - 校验结果默认只打屏显，无法持久化比对；而异地链路存在秒级延迟，必须把 checksum 结果写入一张专用表（用
--replicate指定），再在目标库上用pt-table-sync --sync-to-master对比该表
正确命令示例：pt-table-checksum --replicate=test.checksums --no-check-binlog-format --recursion-method=none --host=beijing-db --user=chk --password=xxx
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
校验前必须确认两地的 binlog_format 和 server_id 配置是否兼容
很多团队在校验失败后才回头查配置。异地多活链路中，binlog_format=ROW 是硬性前提，否则 pt-table-checksum 生成的校验语句无法被下游正确解析执行；而 server_id 必须全局唯一，否则双向同步时会出现事件被自己忽略或重复应用，导致 checksum 表内容错乱。常见错误现象包括：
- checksum 表里某张表的
this_crc字段全为NULL（说明校验 SQL 没执行成功） - 同一张表在两地 checksum 表中
cnt（行数）不一致，但人工抽样查数据是相同的（典型server_id冲突导致部分 chunk 被跳过） - 校验过程中触发大量
duplicate entry报错（binlog_format=STATEMENT下函数/时间类字段非确定性导致）
最终一致性校验不是一次性动作，而是持续可观测的闭环
真正落地的异地多活系统，不会靠人工跑一次 pt-table-checksum 就宣告“数据一致”。它必须嵌入到日常运维流中：
- 每天凌晨低峰期自动触发全量校验，并将差异表名、差异行数写入监控系统（如 Prometheus + Alertmanager）
- 对高频变更表（如订单状态表）启用增量校验：基于
gtid_executed或binlog position定位最近 5 分钟变更的 chunk，每 10 分钟跑一次 - 校验发现差异后，不直接修复，而是先查
show binlog events确认该 chunk 对应的同步延迟是否仍在容忍窗口内（例如设定 RPO ≤ 3s，则延迟 ≤ 3s 的差异视为“尚未收敛”，不告警）
最容易被忽略的一点：校验工具本身不解决冲突，它只告诉你“哪里不一致”。而异地多活里，不一致可能是 LWW 规则下合法的中间态——你得结合业务语义判断这是 bug 还是设计如此。
