首页 > 数据库 >数据特征采样在 MySQL 同步一致性校验中的实践

数据特征采样在 MySQL 同步一致性校验中的实践

时间：2024-07-04 11:30:55浏览次数：17  
标签：采样 校验 pad MySQL CRC32 数据 id CONCAT

作者：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%以上）的校验需求，不论是纯粹的全量还是涉及到增量的场景，都可以完成定点形式的数据一致性校验能力，但总的来说，它也存在可以优化改进的点：

  1. 本质上，块的特征计算值（MD5或CRC32）一致，还是存在内容实际不一致的可能性，虽然这部分概率很低，需要在当前基础上寻找更精确可靠的采样计算方式。

  2. 目前提供的一致性校验方案，只能支持同构型的数据库间，例如本文介绍的mysql->mysql（pg,tidb等），DTS支持的其它数据场景（redis->redis/kv）也是类似的情况，对于异构数据（例如订阅），暂时就没有比较好的方案可以做端对端的校验，需要使用方抽检部分或核心数据。

标签：采样,校验,pad,MySQL,CRC32,数据,id,CONCAT
From： https://www.cnblogs.com/vivotech/p/18283300

相关文章

  • 理解MySQL存储引擎：掌握数据存储与管理
    在工作或学习过程中，作为一名数据库管理员或开发者，我们常常需处理大量数据，同时确保数据的可靠性与高效性。MySQL作为最受欢迎的开源数据库之一，其强大的性能和灵活性广为人知。而在MySQL背后的存储引擎则起到了至关重要的作用。本文将详细介绍MySQL各种存储引擎的特性、用途及......
  • Windows上实现jdk、Mysql(含数据)整体环境和配置以及数据迁移复用(Bat中实现jdk、mysq
    场景若依前后端分离版手把手教你本地搭建环境并运行项目：https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/108465662前后端分离的系统，需要部署在windows服务器上，若后期需要部署的机器较多，则每台机器都需要安装jdk、配置jdk环境变量、安装mysql、配置mysql环境变量......
  • doris 数据库与mysql的不同之处
    1.doris与mysqldoris可以使用mysql驱动进行连接，也支持mysql的部分语法。2.具体分析 清空表数据在mysql中，清空表数据有两种方式：一种是deletefromtable_name，一种是truncatetabletable_name。而在doris中，清空表数据只能使用truncatetabletable_name。deletefrom......
  • vue3+node.js+mysql+electron+express实现用户登录，文章写入删除，全量更新，增量更新，和截
    第一件事情是安装node.js,去官网下，在终端node-v，npm-v有版本号就行了，不必搞环境配置，保姆级别教程，感谢哥有时间。嘻嘻，祝大家开心。1.首先你要创建electron项目打开vscode，新建终端输入代码npminit这个代码是初始化的意思会生成一个文件package.json里面的代码应该是这......
  • 搭建论坛和mysql数据库安装和php安装
    目录概念步骤安装mysql8.0.30安装php安装Discuz概念搭建论坛的架构：lnmp+DISCUZ l表示linux操作系统n表示nginx前端页面的web服务m表示mysql数据库用来保存用户和密码以及论坛的相关内容p表示php动态请求转发的中间件步骤（已经提前安装了nginx）1.关闭......
  • MySQL网络安全&容灾备份
    网络安全主要三个方面。一般云厂商都提供网络相关的安全：白名单、私有网络、SSL加密等。 网络：  MySQL服务器与客户端连接安全SSL（TLS）加密传输。  账户使用较弱的密码或不使用密码，账号安全。valited_password。  账号权限，最小化原则。  网络访问控制，云厂商使用白名单......
  • MySQL-表级锁（表锁、元数据锁、意向锁）
    文章目录1、表级锁介绍1.1、对于表级锁，主要分为以下三类：2、表锁2.1、对于表锁，分为两类：2.2、共享读锁2.2.1、创建表score2.3、独占写锁3、元数据锁3.1、查看数据库中的元数据锁的情况4、意向锁4.1、假如没有意向锁4.2、有了意向锁之后4.3、查看意向锁及行锁的加锁情......
  • MySQL-16.MVCC(多版本并发控制)
    C-16.多版本并发控制1.什么是MVCCMVCC（MultiversionConcurrencyControl），多版本并发控制。顾名思义，MVCC是通过数据行的多个版本管理来实现数据库的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一事务更新的行，并且......
  • 不锈钢酸退作业区冷线氮氧分析仪采样系统优化改造
    不锈钢酸退作业区冷线氮氧分析仪采样系统优化改造一、项目提出前状况：（一）不锈钢酸退作业区酸洗线脱氮系统使用的废气监测仪器氮氧分析仪属于环保设备，数据检测的准确性直接影响环保指标，因此一旦数据检测有误，势必会引起环保事件。脱氮系统是将酸洗过程中产生的酸雾通过燃烧后，......
  • csrf跨站请求,钓鱼网站实现示例,CSRF校验,CSRF相关装饰器,Auth模块,扩展Auth表
    ⅠDjango框架之csrf跨站请求【一】跨站请求伪造介绍【1】引入CSRF（Cross-SiteRequestForgery）跨站请求伪造是一种常见的网络攻击方式。攻击者通过诱导受害者访问恶意网站或点击恶意链接将恶意请求发送到目标网站上利用受害者在目标网站中已登录的身份来执行某些操作从而......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99