作者：vivo 互联网存储研发团队 - Shang Yongxing

本文介绍了当前DTS应用中，MySQL数据同步使用到的数据一致性校验工具，并对它的实现思路进行分享。

一、背景

在 MySQL 的使用过程中，经常会因为如集群拆分、数据传输、数据聚合等原因产生流动和数据复制。而在通常的数据复制过程中，因为涉及到目标的写入不可控、服务应用的未知问题、人为导致的异常缺陷等，很难保证复制产生的数据与源完全一致。除了通过完善流程与服务应用的能力和可靠性来保障数据一致性外，也需要提供快速有效的数据校验机制，便于发现存在异常的数据位置，服务于后续可能的自动重试或人工修订。

而具体到我们目前使用的数据传输服务DTS（MySQL部分），需要考虑的点：

端对端从源集群到目标集群的外部数据校验
内部数据校验机制，确保同步的数据正确可靠

二、选型参考

数据一致性校验，即对DTS的数据同步任务在目标产生（复制）的表数据，与在源库的原始数据进行对比，并给出对比结果。若存在不一致的情况则给出具体不一致的数据块，方便用户快速对不一致数据进行处理。它的基本原则是作为独立一个环节，既不能影响同步本身，也不能影响业务数据库的正常使用。

为了达成数据一致性的校验，需要具备以下的能力：

校验的范围应当包括库表对象的结构、实际行数据已经其它被任务定义包含在内的内容（索引、视图、存储过程等）。
校验应当在保证较小地侵入影响数据库的同时，尽快完成涉及数据的对比检查。
校验应当具备精确定位不一致数据块的位置的能力，用于支持后续进行的数据修订。

三、端对端的数据一致性校验

3.1 现有问题

在数据传输的场景中，相关的数据大概率分散在无关的不同实例上，这种情况下想要对两端的数据进行对比分析，比较包括结构、索引、列数据等维度，当然可以通过最直接的逐行逐列地遍历各个表方式，这种方式最直观且可以最精确地对比相关的数据，但显然如果数据总量或数据列的规模较大时，这种逐行对比的方式会存在下列问题：

执行耗时长
结果时效性差，增量场景几乎无法使用

一般来说如果无法接受"全量"性质的扫描带来的时间开销，可以将"全量"转换为"部分"的验证，本质上一些数据同步场景后执行的点检就是数据的部分校验，这种方式完成速度快，可用于关键数据的快速验证，但这种形式也存在明显的问题：

数据集覆盖度难以平衡
如果确实存在一些不一致的情况，可能会被遗漏

针对这些问题，也许可以采取一些额外的校验保障，例如数据集大小（行数等）的校验，一定程度上可以降低数据不完整的错判风险。

那么回到我们的实际使用场景中，为了解决数据可靠性的问题，我们调研了几种比较主流的MySQL数据校验方案：

pt本身更常被运维用于检查集群内主从的表数据是否一致，这显然与数据传输的场景存在较大的出入，不符合我们的实际需求。

px在实现上更满足数据传输场景的需求，同时包括上述两者在内，一些公用云的MySQL类型数据库的数据一致性校验也是采用类似部分采用数据进行比对的形式：

表的数据分块

不分支持动态分块大小来调整负载

分块级的数据特征计算→简化对比规模

这个思路在数据遍历的完整性和效率方面均做了一定的取舍，相当于是一种中间状态。

而为了达成满足一些定制场景以及提高使用效率的目的，我们最终是采用了px-table-checksum的实现思路来完成的数据校验实现，接下来以一个具体的表结构来介绍进行数据对比的思路。

sysbench在MySQL的压测场景产生的一种表结构如下：

前文我们已经提到虽然直接使用全表逐行对比会存在时间消耗较大的问题，但如果业务属性上源和目标的表发生变化的频率很低（定时更新类），这种校验也是可以发挥作用的：

SELECT id, k, c, pad FROM sbtest1 limit n;

基于这样简易的抽取逻辑进行逐行的比对是可以做到完全校验的，代价就是时间上的开销非常大。

3.2 实现思路

而我们将要采取的分块获取数据的方式则是在这一基础上进行了优化，我们逐步介绍逻辑，首先这里假定使用的分块大小为10行--chunk_size=10

1.数据分块

mysql> SELECT * FROM sbtest1 FORCE INDEX(`PRIMARY`) WHERE ((`id`>= 1) AND  ((`id`) <= 10));
 
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k       | c                                                                                                                       | pad                                                         |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
|  1 | 3230682 | 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441 | 22195207048-70116052123-74140395089-76317954521-98694025897 |
|  2 |  556124 | 13241531885-45658403807-79170748828-69419634012-13605813761-77983377181-01582588137-21344716829-87370944992-02457486289 | 28733802923-10548894641-11867531929-71265603657-36546888392 |
|  3 | 2757236 | 16516882386-05118562259-88939752278-62800788230-55205008755-06868633780-74894238647-69655573455-70526404237-73358617781 | 73198647949-50059256035-48039302709-77824424754-93913530645 |
|  4 | 3080419 | 88936868384-35413314949-47572298747-62301572168-04725458949-84024294746-95505588496-92367527122-22018143923-07447340456 | 35540797267-28848817162-69859656941-29402637497-25804052865 |
|  5 | 2755665 | 38000028170-70584813101-64973736504-76149487237-52945047102-11275974719-79041047383-53171259040-17278926045-71359842623 | 24429914423-05032864825-55698585282-50062977513-27378309065 |
|  6 | 1689856 | 90918476202-02089391467-64272595615-72064149272-80467152282-18848936545-61767310237-38205570677-59195835610-06087350040 | 37783104634-08719671341-44662007841-24831185436-08450447859 |
|  7 |  367648 | 69873895168-42508713642-77344499431-18964268934-99713628807-43846750254-87716358839-40367934805-98231362293-37861509854 | 65003009667-83421336486-43798350655-86517975104-79705317753 |
|  8 | 4069722 | 03426487304-27156530652-16106764306-84175870374-36434920674-38029783924-53173822921-96186178437-58319716571-95077711704 | 31784578367-14387657451-27946335198-02419089416-67782425795 |
|  9 | 4608666 | 81689156752-44921640552-35987563480-16691191991-27936686268-18588338593-16235034269-90308874838-52095870672-98075954786 | 03144707666-87793208474-21823431822-18751222077-39980824756 |
| 10 | 2975029 | 03392914016-90098596959-72565142257-56206208928-54469213163-80095083408-91183949560-45926629535-07758798231-14358688386 | 44959141897-52907315042-08586003451-12076203782-52848887604 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+

2.按列聚合

mysql> SELECT CONCAT_WS('#', `id`, `k`, CRC32(`c`), CRC32(`pad`), CONCAT(ISNULL(`pad`))) AS CRC FROM `sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id`>= 1) AND  ((`id`) <= 10));
 
+-----------------------------------+
| CRC                               |
+-----------------------------------+
| 1#3230682#4041434652#3764881225#0 |
| 2#556124#847118261#777674597#0    |
| 3#2757236#2890838841#3354864368#0 |
| 4#3080419#2053219065#3018733667#0 |
| 5#2755665#4230533455#266494007#0  |
| 6#1689856#2940387143#1608825719#0 |
| 7#367648#2894429300#3186127078#0  |
| 8#4069722#1825802258#3718534773#0 |
| 9#4608666#1487055134#1908388285#0 |
| 10#2975029#1272074468#264227369#0 |
+-----------------------------------+

3. 按行聚合

在前一步的基础上，可以再计算一次当前聚合列的CRC32值使长度减少(因为按列聚合时使用的group_concat可能会存在长度的限制，这也是需要关注的问题）

mysql> SELECT CRC32(CONCAT_WS('#', `id`, `k`, CRC32(`c`), CRC32(`pad`), CONCAT(ISNULL(`pad`)))) AS CRC FROM `sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id`>= 1) AND  ((`id`) <= 10));
  
+------------+
| CRC        |
+------------+
|  501470676 |
| 3723711314 |
| 4091031521 |
|  571991173 |
| 3184804606 |
| 1525903855 |
| 3331492255 |
|  105586567 |
| 3803559186 |
| 3193672787 |
+------------+  
 
mysql> SELECT GROUP_CONCAT(CRC32(CONCAT_WS('#', `id`, `k`, CRC32(`c`), CRC32(`pad`), CONCAT(ISNULL(`pad`))))) AS CRC FROM `sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id`>= 1) AND  ((`id`) <= 10));
 
+------------------------------------------------------------------------------------------------------------+
| CRC                                                                                                        |
+------------------------------------------------------------------------------------------------------------+
| 501470676,3723711314,4091031521,571991173,3184804606,1525903855,3331492255,105586567,3803559186,3193672787 |
+------------------------------------------------------------------------------------------------------------+

4.特征计算

到这一部分为止，我们可以将这种类型的CRC值作为这10行4列数据块的一种"特征"，用它来代表这部分数据，可以进一步进行压缩来提高比对效率，可选md5或继续CRC32等计算方式。

mysql> SELECT CRC32(GROUP_CONCAT(CRC32(CONCAT_WS('#', `id`, `k`, CRC32(`c`), CRC32(`pad`), CONCAT(ISNULL(`pad`)))))) AS CRC FROM `sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id`>= 1) AND  ((`id`) <= 10));
+------------+
| CRC        |
+------------+
| 3337375759 |
+------------+
 
mysql> SELECT md5(GROUP_CONCAT(CRC32(CONCAT_WS('#', `id`, `k`, CRC32(`c`), CRC32(`pad`), CONCAT(ISNULL(`pad`)))))) AS md5 FROM `sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id`>= 1) AND  ((`id`) <= 10));
+----------------------------------+
| md5                              |
+----------------------------------+
| 6b2fb38d05fee0733382f2e4d6dc2f91 |
+----------------------------------+

实际使用中使用更大的数据块来进行映射，能加快校验的速度：

数据块越大，特征的精度越低，但匹配校验的速度越快，对源和目标的负载越大。
数据快越小，特征的精度越高，但匹配校验的速度越慢，对源和目标的负载越小。

相对应的，以上是在源计算对应块的特征，在目标以同样的形式计算可以得到一个"类似"的结果，通过对它进行比对，可以判断两块数据的特征是否一致。但这同样也有一些问题：

概率上存在特征值相同但数据存在差异的情况，无法避免。
比对的块依赖主键ID，不允许在目标存在主键覆盖的情况（源的数据因主键冲突被跳过）。

若存在数据不一致（块之间的CRC32值不一致），此时可以基于当前chunk的上下边界（upper/lower bound）进行进一步切分，通过精确的数据对比来定位到不一致的行。

数据最终一致性

前文中的例子更偏向于一个单纯的全量数据抽取场景，如果目标的数据存在一定程度上的变化时，如何对应处理呢？

差异块的重复校验

我们需要解决两个问题：尽可能在机制上确保数据不会出错，若存在异常或无法处理的情况应当以中断同步为优先选择；同时需要在端对端数据校验的基础上覆盖增量的数据同步场景。

数据校验任务并不是持续运行的场景，它应当是在低峰期、同步延迟1秒内或在业务要求的情况下发生的行为，那么基于数据同步的最终一致性特征，当增量场景下校验出某些块存在差异时：

例如：

两侧的chunk[1001-2000]存在差异，那么需要按照精细拆分地形式定位到具体的差异行，一般基于binlog的延迟在0秒（1秒内）时，行的差异数量是有限的，可以对其进行全部的记录或抽样记录。

在一定的时间间隔后重新校验上一次记录中的差异行，判断是否最终达成了一致；

可能存在特殊的场景，只频繁更新某一行，导致校验一直无法判断两端一致。

四、总结与思考

经过一定时间的线上实际应用，这种方案确实可以解决绝大部分（99%以上）的校验需求，不论是纯粹的全量还是涉及到增量的场景，都可以完成定点形式的数据一致性校验能力，但总的来说，它也存在可以优化改进的点：

本质上，块的特征计算值（MD5或CRC32）一致，还是存在内容实际不一致的可能性，虽然这部分概率很低，需要在当前基础上寻找更精确可靠的采样计算方式。
目前提供的一致性校验方案，只能支持同构型的数据库间，例如本文介绍的mysql->mysql（pg,tidb等），DTS支持的其它数据场景（redis->redis/kv）也是类似的情况，对于异构数据（例如订阅），暂时就没有比较好的方案可以做端对端的校验，需要使用方抽检部分或核心数据。