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

  • 时间:
  • 浏览:0
  • 来源:大发5分快3_极速5分PK10

统统就要用到分页查询,根据(自增或联合)主键、唯一索引,每次limit 50000后升序取最后二根,作为下一批的起始。统统要分析表上的键清况 ,组合查询条件。目前仅能检查有主键或唯一统统的表。

主从环境下数据一致性校验时不时会用 pt-table-checksum 工具,它的原理及实施过程前一天写过一篇文章:生产环境使用 pt-table-checksum 检查MySQL数据一致性。因此DBA工作中前会统统针对有另兩个 表检查算是 一致,而这有另兩个 表之间并那么主从关系,pt工具是基于binlog把在主库进行的检查动作,在从库重放一遍,此时就不适用了。

该python线程基于2.7开发,2.6、3.x上那么测试。使用前须要安装 MySQLdbhotqueue

项目地址:https://github.com/seanlook/px-table-checksum

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

原文链接地址:http://seanlook.com/2016/11/20/py-mysql-table-checksum-non-replicas/

要比较的表和选项,使用全配置化,即不通过命令行的最好的办法指定(原谅命令行参数使用最好的办法会额外增加代码量)。

DO_COMPARE: 运行模式

统统才萌生了参考 pt-table-checksum 当时人写了有另兩个 :px-table-checksum 。

总会有另兩个 特殊的需求,比如从阿里云RDS实例迁移到自建mysql实例,它的数据传输服务实现最好的办法是基于表的批量数据提取,加带binlog订阅,但强制row模式会意味pt-table-checksum那么权限把会话临时改成statement。另一种需求是,整库进行字符集转换:库表定义就有utf8,但应用连接使用了默认的 latin1,要将连接字符集和表字符集统一起去来,不可否以latin1导出数据,再以utf8导入,一种清况 数据一致性校验,且不说binlog解析线程不支持statement(如canal),新旧库一种内容不同,pt-table-checksum 算出的校验值也会不一样,失效。

但为了尽肯能减少此类那些的问提(比如主从延迟也肯能会),特意设计了多个redis队列,目标库多个检查线程,即比如一起去指定检查8个表,源库检查会有8个线程对应,但可否根据表的写入清况 ,配置有另兩个 redis队列(目前是随机入列),10个目标库检查线程,来减少不准确因素。

但站在我的角度往往来说,不一致的数据会被记录下来,肯能越多,人工核对一下;肯能较多,就再跑一遍检查,肯能两次就有同二根数据不一致,那就有清况 了。

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

上面的配置文件可否认为是用于控制线程的,一种配置文件是指定要校验的源库和目标库信息,以及要检验那些表。

那么那些的问提就在于:

统统须要保证相同编号的chunk,起点须要相同,统统想到用队列,存放进源库跑过的所有校验sql,模拟pt工具在目标库重放。考虑到要线程一起去比较多个表,队列肯能吃内存过大,于是使用了redis队列。

配置选项