技术分享 | 两个单机 MySQL 该如何校验数据一致性

业务有两个 MySQL 集群是通过 MQ 进行同步的，昨晚 MQ 出现异常，报了很多主键冲突，想请 dba 帮忙校验一下两个集群的数据是否一致。

当接到这个需求的时候并没当回事，隐约有点印象 pt-table-checksum 能通过 dsn 实现 MySQL 的数据校验，所以当时就应承下来了。不曾想，啪啪打脸，回想起来真是草率了。

本文参考的是 pt-table-checksum 的校验逻辑，基于数据块去遍历每个表，然后比对 checksum 的值判断该块是否一致，本文主要是想聊聊我在实现数据校验脚本过程中遇到的问题以及解决思路，希望对大家有帮助。

利用线上的配置文件搭建一套主从环境。

这个用例将通过 dsn 方式连接从库。

这个用例将通过 dsn 方式连接从库，但是会将从库的复制链路 stop 掉，并清空复制信息。

熟悉 pt-table-checksum 的朋友应该都知道，该工具是基于主键(非空唯一键)进行扫描数据行，其实这个逻辑针对整型单列主键实现起来很简单，但是如果是联合主键且是字符型，好像就没那么简单了，有兴趣的可以思考一下。下面我先说一下大致的逻辑：

第一步：判断 _min_rowid 是否为空，为空就取该表的第一行，并记作 _min_rowid 。

第二步：根据 _min_rowid 作为条件进行扫描该表，取下一个数据块的数据，记录数据块的最后一行数据的主键值，记录 checksum 的值，并记下 _min_rowid 。

第三步：判断_min_rowid是否为空，非空重复第二步，为空退出检查。

通过上述三个步骤可以看到，如果是单列整型的主键，实现起来很简单，但是问题来了，业务的表的主键五花八门，有的是联合主键，有的是字符型的联合主键，还有整型+字符型的联合主键，那么上述的实现方式显然是有问题的。所以实现起来需要多考虑几个问题：

鉴于存在上述两个问题，可以参考如下实现逻辑：

假如有这么一个联合主键字段 primary key(a,b,c) 都是整型，该如何编写遍历 sql 呢？起初我的想法很简单，具体如下：

至此在编写校验脚本过程遇到的两个问题就算告一段落了，剩下的就是各种逻辑处理了，不过多赘述，有兴趣的可以自行阅读脚本文件。

本着最低程度影响业务，所以取消加锁逻辑。但是又要保证该数据块的数据一致性，如果这个数据块是个热数据，当前正在变更，那么校验的时候难免会不一致。所以只能通过多次校验实现，默认是校验20次，其中有一次校验结果是一致，就认为是一致的，如果前5次校验过程中，这个数据块的数据没有变化，也视为不一致（可能是因为延迟，也可能是真的不一致）。

pt-table-checksum 不校验表结构，改写时添加表结构的校验。

可以基于表的并行校验，可由用户指定并行数，但是脚本有个安全机制，如果用户指定的并行数大于当前 cpu 空闲核心数，就会按当前（空闲核心数-1）作为并行数。

添加网络监控，由用户指定网络上限百分比，当网卡流量超过这个百分比就暂停任务，等待网卡流量低于阈值才会继续任务。这个主要是出于对于中间件（mycat）的场景或者分布式数据库（tidb）的场景。

支持定时任务功能，用户可以使用这个功能规避业务高峰，仅在业务低峰进行数据校验。

不仅限于主从节点的校验，只要目标对象支持 MySQL 的标准 SQL 语法就能做数据校验。

校验逻辑是通过 SQL 采集目标节点的数据库，如果目标数据库系统当前存在异常，无疑是雪上加霜，将会触发未知问题，所以添加超时机制，单次取数据块的阈值是5s，超过5秒就放弃等待重试。测试发现，有时候即便触发超时了，但是 SQL 任务还是会在目标数据库的 processlist 中能看到，所以又添加了一个 kill 机制，超时后会触发一个 kill processlist id 的动作。另外为了避免 kill 错，在每个 SQL 对象添加了一个32位的 md5 值，每次 kill 的时候会校验这个 md5 值。

本工具借鉴 pt-table-checksum 工具思路改写，可以检查随意两个 mysql（支持 mysql sql 语法的数据库）节点的数据一致性。

基于主键以一个块遍历数据表，比对checksum的值，块的大小可通过参数指定。 （1）获取该表的第一个数据块的查询SQL。 （2）将两个目标节点的数据块的checksum的值，记录到临时文件，file1 file2。 （3）比对file1 file2是否一致。

第一步：先开启一个 screen 监控网络

第二步：新开启一个screen执行校验任务

（1）info.log 文件

（2）list目录

（3）md5 目录

（4）pri 目录

（5）res 目录

这是 table 目录下记录某个数据块不一致的一个例子

这是 diff 目录下记录某个数据行不一致的一个例子

（6）skip.log 文件

本工具是参考了 pt-table-checksum 工具的一些思路并结合自身经验进行改写，尚有很多不足之处，仅做学习交流之用， 如有线上环境使用需求，请在测试环境充分测试。

如何保证redis集群和mysql的数据一致性

如果要“保证”数据的安全性，那么会带来开销的进一步提升，以至于使用redis带来的性能优势都会丧失。正确的做法是区分不同的业务，使得并不需要“保证”数据一致性的场合，可以使用redis优化。而敏感的场合依然使用mysql。

基本概念

1、什么是 Scrub

Scrub是 Ceph 集群副本进行数据扫描的 *** 作，用于检测副本间数据的一致性，包括 scrub 和 deep-scrub。其中scrub 只对元数据信息进行扫描，相对比较快；而deep-scrub 不仅对元数据进行扫描，还会对存储的数据进行扫描，相对比较慢。

2、Scrub默认执行周期

OSD 的scrub 默认策略是每天到每周（如果集群负载大周期就是一周，如果集群负载小周期就是一天）进行一次，时间区域默认为全体（0时-24时），deep-scrub默认策略是每周一次。

配置scrub策略

为了避开客户业务高峰时段，建议在晚上0点到第二天早上5点之间，执行scrub *** 作。

1、设置标识位

在任一monitor节点进行如下 *** 作:

2、临时配置

先通过tell 方式，让scrub 时间区间配置立即生效，在任一monitor节点进行如下 *** 作:

3、修改配置文件

为了保证集群服务重启或者节点重启依然有效，需要修改Ceph集群所有节点的配置文件 /etc/ceph/ceph.conf

添加以下区段配置：

注意: 该时间设置需要参考物理节点的时区设置

4、取消标识位

5、向 OSD {osd-num} 下达一个scrub命令. (用通配符 * 把命令下达到所有 OSD 。实测ceph 12.2.x版本不能加*)

6、设置 light scrub 周期

将osd_scrub_min_interval 和 osd_scrub_max_interval都设为4分钟,这里的单位是秒

7、通过命令手动启动scrub ：

8、尝试 pg repair

9、(Deep)Scrub的相关配置选项

同前端IO和Recovery一样，Ceph通过控制PGScrub来间接控制Scrub的所有IO优先级。

---