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

  • 时间:
  • 浏览:2
  • 来源:大发5分排列5_极速5分排列3

主从环境下数据一致性校验时不完会用 pt-table-checksum 工具,它的原理及实施过程已经 写过一篇文章:生产环境使用 pt-table-checksum 检查MySQL数据一致性。就说 DBA工作中一定会就说 针对那我表检查与否一致,而这那我表之间并找不到主从关系,pt工具是基于binlog把在主库进行的检查动作,在从库重放一遍,此时就不适用了。

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

找不到问题图片就在于:

该python程序运行基于2.7开发,2.6、3.x上找不到测试。使用前须要安装 MySQLdbhotqueue

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

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

DO_COMPARE: 运行模式

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

所以才萌生了参考 pt-table-checksum 个人写了那我:px-table-checksum 。

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

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

但为了尽就说 减少此类问题图片(比如主从延迟也就说 会),特意设计了多个redis队列,目标库多个检查程序运行,即比如一齐指定检查8个表,源库检查会有8个程序运行对应,但都可以 根据表的写入清况 ,配置那我redis队列(目前是随机入列),10个目标库检查程序运行,来减少不准确因素。

但站在我的深度图往往来说,不一致的数据会被记录下来,就说 找不到来不要 ,人工核对一下;就说 较多,就再跑一遍检查,就说 两次一定会同十根绳子 数据不一致,那一定会清况 了。

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

后边的配置文件都可以 认为是用于控制程序运行的,五种配置文件是指定要校验的源库和目标库信息,以及要检验那些表。

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

配置选项