主从数据一致性校验与修复：chunk 对账、pt-table-checksum 与增量修复实战

主从不一致的常见根因：
  · binlog 格式问题（非 ROW，或 mixed 下函数非确定性）
  · 从库复制中断后手动补数错位
  · 从库被误写（人为/程序绕过只读）
  · 半同步降级为异步期间的主从窗口
  · 主库崩溃未完全 flush 导致的差异
  · 存储引擎差异 / 表结构不一致
  · 大事务 / 长延迟期间的并发写覆盖

关键事实：
  · MySQL 复制"尽力而为"，不保证强一致
  · 不校验 = 不一致可能在未知时间点悄悄产生
  → 一致性校验是"复制健康"的体检，必须周期性做

① 抽样对比：随机抽行/按 id 抽样，速度快，有盲区
② 全量对账：逐块比对（chunk + checksum），彻底，慢

生产实践：全量对账为主（周期性），抽样为辅（日常快速巡检）

-- 错误示范：主从各 COUNT
SELECT COUNT(*) FROM orders;    -- 主库
SELECT COUNT(*) FROM orders;    -- 从库
-- 行数相等 ≠ 数据一致（可能内容不同，COUNT 不看内容）
-- 且大表 COUNT 全表扫描，代价极高

pt-table-checksum 的核心算法：
  1. 按主键把表切成多个 chunk（每 chunk 约 1000-2000 行）
  2. 对每个 chunk 计算 checksum（行内容哈希）
  3. 主从都算同一 chunk 的 checksum 并对比
  4. 差异 chunk → 精确到行定位

chunk 划分好处：
  · 内存可控（每次只处理一小块）
  · 锁影响小（只锁 chunk 范围）
  · 可增量/可断点续跑
  · 主从并行对比，吞吐高

-- pt-table-checksum 本质执行的 SQL（示意）
-- 主库计算 chunk 校验：
SELECT CRC32(CONCAT_WS('#', id, name, amount, ...))
FROM orders
WHERE id BETWEEN ? AND ?;
-- 从库同样计算并对比

checksum 函数：
  · CRC32：快，碰撞概率低（32bit）
  · MD5 / SHA：更稳但更慢
  · pt-table-checksum 默认组合算法（F CRC32）

注意：
  · 浮动/浮点列可能因平台差异产生不一致（用 round）
  · 时间列注意时区差异
  · 大字段（BLOB/TEXT）用 CRC32(CONCAT(bit_count...)) 处理

# 全库校验（dsn 指向主库，工具自动感知从库）
pt-table-checksum \
  --host=mysql-master \
  --user=check \
  --password=*** \
  --databases=orders_db \
  --tables=orders \
  --replicate=percona.checksums \
  --no-check-binlog-format \
  --chunk-size=1000 \
  --empty-replicate-table

# 输出解读：每行一个表，TS/DIFFS/ROWS/CHUNKS
# DIFFS>0 表示有差异 chunk

-- 校验结果存在 percona.checksums 表
SELECT * FROM percona.checksums
WHERE master_cnt <> this_cnt OR master_crc <> this_crc
LIMIT 10;
-- 每个 chunk 一行：master_crc（主库校验值） vs this_crc（当前库）

# 控制负载与频率
--max-lag=1                    # 从库延迟超 1s 自动等待
--check-interval=1             # 检查从库延迟间隔
--chunk-size=1000              # 每 chunk 行数（越大越快但锁更久）
--chunk-size-limit=4           # 动态 chunk 上限
--max-load Threads_running=200 # 主库负载过高自动节流
--lock-wait-timeout=30
# 表过滤
--databases / --tables / --ignore-tables
# 跳过不确定列
--no-check-binlog-format / --nocheck-replication-filters

# 典型调度（低峰 + 大表分表跑）
0 3 * * 0  pt-table-checksum --databases=core_db --max-lag=2 > /var/log/consistency/checksum.log

-- 校验账号所需权限
GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'check'@'%';
-- SUPER/PROCESS 用于 SHOW SLAVE STATUS 检测延迟与锁等待

-- 用 checksums 表定位差异 chunk 的 id 范围
SELECT db, tbl, chunk, lower_boundary, upper_boundary,
       master_cnt, this_cnt, master_crc, this_crc
FROM percona.checksums
WHERE db='orders_db' AND tbl='orders' AND master_crc <> this_crc;

-- 然后精确对账差异范围：
-- 主库
SELECT * FROM orders WHERE id BETWEEN ? AND ? ORDER BY id;
-- 从库
SELECT * FROM orders WHERE id BETWEEN ? AND ? ORDER BY id;
-- 逐行对比

# 先 dry-run 看会改什么（强烈建议）
pt-table-sync \
  --execute \
  --dry-run \
  --replicate=percona.checksums \
  --tables orders_db.orders \
  D=orders_db,h=mysql-master,u=check,p=***

# 确认无误后真正执行（仅在差异 chunk 上做最小 DML）
pt-table-sync \
  --execute \
  --replicate=percona.checksums \
  --tables orders_db.orders \
  D=orders_db,h=mysql-master,u=check,p=***

方式一：基于 checksums 表定位（推荐）
  只修有差异的 chunk → 最小化影响
  --replicate=percona.checksums 让工具"按差异点修复"

方式二：全表同步（慎用）
  不指定 replicate，逐表逐行对齐
  → 适合差异少、可短锁的表

原则：
  · 以主库为准（数据一致性锚点 = 主库）
  · 修复动作 = 把从库改到与主库一致
  · 先备份差异行再做修复（可回滚）

# 修复工具会持有锁（DML + 行锁），选择低峰执行
# 修复前：
#   1) 记录差异清单
#   2) 评估差异行数（大差异 = 先复盘根因再修）
#   3) 若差异来自"复制断流"，先恢复复制
# 修复后：
#   1) 重新跑 checksum 验证
#   2) 检查复制延迟/错误
#   3) 分析根因并加防护（只读、延迟监控）

-- 检查复制状态
SHOW REPLICA STATUS\G;
-- 常见问题：SQL 线程停止（错误码 1062 主键冲突等）
-- 恢复方式：
--   小额差异：STOP REPLICA; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START REPLICA;
--   严重差异：需 re-position / 重建从库

# 差异过大 / 无法增量修复时：重建从库
# 用备份（Xtrabackup）+ binlog 增量搭从库
xtrabackup --backup --target-dir=/backup
# 传到新从库，恢复后 change master 到主库

对账平台组成：
  · 调度器：周期性触发校验（cron / 工作流）
  · 校验执行：pt-table-checksum 或自研 chunk 校验
  · 结果存储：差异明细入库（audit 表）
  · 告警：差异数 > 0 → 通知 DBA
  · 修复流程：人工确认 → pt-table-sync / 自研修复
  · 报表：校验覆盖率、差异趋势

触发策略：
  · 全量校验：每周/每月（低峰）
  · 增量校验：每日对变化大的表
  · 事件触发：复制异常恢复后立即校验

校验对象分层：
  · 核心表（订单/账户/余额）：高频率 + 全量
  · 普通表：中频率 + 抽样
  · 历史/归档表：低频 + 抽样
  · 结构一致性：定期对比 SHOW CREATE TABLE

# 对账平台指标
consistency_check_total                     # 校验次数
consistency_diff_chunks{db,tbl}             # 差异 chunk 数
consistency_diff_rows                        # 差异行数
consistency_repair_duration                  # 修复耗时
consistency_repair_failed                    # 修复失败
# 告警：任何 db.tbl 的 diff_rows > 0

· PostgreSQL 逻辑复制/流复制：
  可用 pg_stat_replication 观察 WAL 接收进度，
  数据一致性用自定义 checksum 查询或 pg_dump 对比抽样
· Redis 多副本：redis-check / keyspace 对比
· 消息队列（Kafka）：offset 对齐是"消费进度"而非数据一致，
  需独立对账（去重 + 幂等消费）

# verify_service.py — 通用 chunk 对账框架
def verify_table(source, target, table, chunk_size=1000):
    """按主键范围逐 chunk 对比两张表。"""
    min_id, max_id = source.range(table)
    diffs = []
    for lo in range(min_id, max_id + 1, chunk_size):
        hi = min(lo + chunk_size - 1, max_id)
        s = source.rows(table, lo, hi)     # 主库 chunk
        t = target.rows(table, lo, hi)     # 从库 chunk
        if s != t:
            diffs.append(find_diff_rows(s, t, table))
    return diffs

# 幂等修复（以 source 为准，可重放）
def repair(s, t, table, key, field):
    for row in s:
        if t.get(key=row[key]) is None or t.get(key=row[key])[field] != row[field]:
            t.upsert(table, row)            # 幂等：重复执行结果一致

□ 校验账号与权限准备
□ 低峰窗口排期（全量 vs 增量）
□ pt-table-checksum 参数调优（max-lag/load 节流）
□ 差异定位流程（checksums 表 → 行级对比）
□ 修复前备份差异行
□ 修复后重校验
□ 对账结果入库 + 告警
□ 根因复盘（为何不一致）+ 防护加固

· 主库是真相源，修复永远以主库为准
· 先恢复复制健康，再谈对账
· 校验要周期化，不是一次性
· 修复要可回滚、幂等
· 每个差异都要追根因（工具只治病，不治病根）