MySQL非主从环境下数据一致性校验及修复程序

1. 简介

项目地址：https://github.com/seanlook/p...

主从环境下数据一致性校验常常会用 pt-table-checksum 工具，它的原理及实施过程以前写过一篇文章：生产环境使用 pt-table-checksum 检查MySQL数据一致性。可是DBA工做中还会有些针对两个表检查是否一致，而这两个表之间并无主从关系，pt工具是基于binlog把在主库进行的检查动做，在从库重放一遍，此时就不适用了。

总会有这样特殊的需求，好比从阿里云RDS实例迁移到自建mysql实例，它的数据传输服务实现方式是基于表的批量数据提取，加上binlog订阅，但强制row模式会致使pt-table-checksum没有权限把会话临时改为statement。另外一种需求是，整库进行字符集转换：库表定义都是utf8，但应用链接使用了默认的 latin1，要将链接字符集和表字符集统一块儿来，只能以latin1导出数据，再以utf8导入，这种状况数据一致性校验，且不说binlog解析程序不支持statement（如canal），新旧库自己内容不一样，pt-table-checksum 算出的校验值也会不同，失效。

因此才萌生了参考 pt-table-checksum 本身写了一个：px-table-checksum 。

2. 实现方法

总体思路是借鉴pt-table-checksum，从源库批量（即chunk）取出一块数据如1000行，计算CRC32值，一样的语句在目标库运行一遍，结果都存入另外一个库，最后检查对应编号的chunk crc值是否一致。知道不一致还不行，得可否快速方便的修复差别，因此继续根据那些不一致的chunk，去目标库和源库找到不一致的行，是缺失，仍是多余，仍是被修改了，而后生成修复sql，根据指示是否自动修复。

那么问题就在于：

1. 如何肯定批次，也就是下一个chunk该怎么取？
   我还没想作到pt-table-checksum那样，能够根据负载动态调整chunk大小，甚至活跃线程数超过阀值就暂停检查，上来工做量就太大了。目前每次计算的chunk的行数是固定的，能够配置1000或2000等。

因此就要用到分页查询，根据（自增或联合）主键、惟一索引，每次limit 1000后升序取最后一条，做为下一批的起始。因此要分析表上的键状况，组合查询条件。目前仅能检查有主键或惟一因此的表。

1. 如何保证源库和目标库，运行的sql同样？
   以前一版是目标库和源库，以多线程各自计算chunk，入库，后来才意识到严重的bug：好比一样是取1000行，若是目标库少数据，那么下一个chunk起始就不同，比较的结果简直一塌糊涂。

因此必须保证相同编号的chunk，起点必须相同，因此想到用队列，存放在源库跑过的全部校验sql，模拟pt工具在目标库重放。考虑到要多线程同时比较多个表，队列可能吃内存过大，因而使用了redis队列。

1. 直接在数据库中计算crc32，仍是取出数据在内存里计算？
   翻了pt-table-checksum的源码，它是在数据库里计算的。可是第一节里说过，若是目标库和源库要使用不一样的字符集才能读出正确的数据，只能查询出来以后再比较。因此 px-table-checksum 两种都支持，只需指定一个配置项。

2. 同时检查多个表，源库sql挤在队列，目标库拿出来执行时过了1s，此时源库那条数据又被修改了一次同步到了目标库，会致使计算结果不一致，实则一致，怎么处理
   没法处理，是px-table-checksum相比pt-table-checksum最大的缺陷。

但为了尽量减小此类问题（好比主从延迟也可能会），特地设计了多个redis队列，目标库多个检查线程，即好比同时指定检查8个表，源库检查会有8个线程对应，但能够根据表的写入状况，配置4个redis队列（目前是随机入列），10个目标库检查线程，来减小不许确因素。
但站在个人角度每每来讲，不一致的数据会被记录下来，若是很少，人工核对一下；若是较多，就再跑一遍检查，若是两次都有同一条数据不一致，那就有状况了。

3. 限制

1. 若是检查期间源表数据，变化频繁，有可能检查的结果不许确
   也就是上面第4点的问题。很明显，这个程序每一个检查的事务是分开的，不像pt工具能严格保证每条检查sql的事务顺序。但有不一致的数据再排查一下就ok了。实际在我线上使用过程当中，99.9%是准确的。

2. 表上必须有主键或惟一索引
   程序会检查，若是没有会退出。

3. varbinay,blob等二进制字段不支持修复
   其实也不是彻底不支持，要看怎么用的。开发若是有把字符先转成字节，再存入mysql，这种就不支持修复。是有办法能够处理，那就是从源库查时用 hex()函数，修复sql里面unhex()写回去。

4. 使用说明

该python程序基于2.7开发，2.六、3.x上没有测试。使用前须要安装 MySQLdb和hotqueue：

$ sudo pip install MySQL-python hotqueue

要比较的表和选项，使用全配置化，即不经过命令行的方式指定（原谅命令行参数使用方式会额外增长代码量）。

4.1 px-table-checksum.py

主程序，运行python px-table-checksum.py 执行一致性检查，但必定了解下面的配置文件选项。

4.2 settings_checksum.py

配置选项

• CHUNK_SIZE: 每次提取的chunk行数

• REDIS_INFO: 指定使用redis队列地址

• REDIS_QUEUE_CNT: redis队列数量，消费者（目标库）有一一对应的线程守着队列

• REDIS_POOL_CNT: 生产者（源库）redis客户端链接池。这个设计是为了缓解GIL带来的问题，把入列端与出列端分开，由于若是表多可能短期有大量sql入队列，避免hotqueue争用

• CALC_CRC32_DB: True 表示在db里面计算checksum值，False表示取出chunk数据在python里面计算。默认给的值是根据链接字符集定的。

• DO_COMPARE: 运行模式

  • 0: 只提取数据计算，不比较是否一致。能够在以后在模式2下只比较

  • 1: 计算，并比较。经常使用，每次计算以前会删除上一次这个待检查表的结果，比较的结果只告诉哪些chunk号不一致。

  • 2: 不计算，只从t_checkum结果比较。经常使用，计算是消耗数据库资源的，能够只对已有的checksum计算结果比较不一致的地方。相似pt工具的--replicate-check-only选项。

• GEN_DATAFIX:
  与DO_COMPARE结合使用，为 True 表示对不一致的chunk找到具体不一致行，并生成修复sql；为 False 则什么都不作。

• RUN_DATAFIX:
  与GEN_DATAFIX结合使用，为 True 表示对生成的修复sql，在目标库执行。须要谨慎，若是哪一次设置了修复，记得完成后改回False，否则下次检查另外一个表就出意外了，因此特地对这个选项再加了一个确认提示。

• DB_CHECKSUM: 一个字典，指定checksum的结果存到哪里
  配置文件有示例，必须指定 db_name，表会自动建立。

4.3 settings_cs_tables.py

上面的配置文件能够认为是用于控制程序的，这个配置文件是指定要校验的源库和目标库信息，以及要检验哪些表。

• TABLES_CHECK: 字典，指定要检查哪些表的一致性，db名为key，多个table名组成列表为value。暂不支持对整个db作检查，同时比较的表数量不建议超过8个

• DB_SOURCE: 字典，指定源库的链接信息

• DB_SOURCE: 字典，指定目标库的链接信息

---

原文连接地址：http://seanlook.com/2016/11/2...