linux校验数据一致,用pt-table-checksum校验数据一致性

内部工作过程

有了上面关键的几点说明,我们再来看看pt工具的内部工作过程,如下图:

936046bf51763c41e396969d6b3087ae.png 简单解释下工作过程:

1. 连接到主库:pt工具连接到主库,然后自动发现主库的所有从库。默认采用show full processlist来查找从库,但是这只有在主从实例端口相同的情况下才有效。

3. 查找主库或者从库是否有复制过滤规则:这是为了安全而默认检查的选项。你可以关闭这个检查,但是这可能导致checksum的sql语句要么不会同步到从库,要么到了从库发现从库没有要被checksum的表,这都会导致从库同步卡库。

5. 开始获取表,一个个的计算。

6. 如果是表的第一个chunk,那么chunk-size一般为1000;如果不是表的第一个chunk,那么采用19步中分析出的结果。

7. 检查表结构,进行数据类型转换等,生成checksum的sql语句。

8. 根据表上的索引和数据的分布,选择最合适的split表的方法。

9. 开始checksum表。

10. 默认在chunk一个表之前,先删除上次这个表相关的计算结果。除非—resume。

14. 根据explain的结果,判断chunk的size是否超过了你定义的chunk-size的上限。如果超过了,为了不影响线上性能,这个chunk将被忽略。

15. 把要checksum的行加上for update锁,并计算。

17-18. 把计算结果存储到master_crc master_count列中。

19. 调整下一个chunk的大小。

20. 等待从库追上主库。如果没有延迟备份的从库在运行,最好检查所有的从库,如果发现延迟最大的从库延迟超过max-lag秒,pt工具在这里将暂停。

21. 如果发现主库的max-load超过某个阈值,pt工具在这里将暂停。

22. 继续下一个chunk,直到这个table被chunk完毕。

23-24. 等待从库执行完checksum,便于生成汇总的统计结果。每个表汇总并统计一次。

25-26. 循环每个表,直到结束。

校验结束后,在每个从库上,执行如下的sql语句即可看到是否有主从不一致发生:

select * from percona.checksums where master_cnt <> this_cnt OR master_crc <> this_crc OR ISNULL(master_crc) <> ISNULL(this_crc) \G

重要选项

安全选项:

—check-replication-filters 是否检查复制过滤规则

—check-slave-tables 检查是否所有从库都有被检查的表和列

—chunk-size-limit 每个chunk最大不能超过这个大小,超过就忽略它

限速选项:

—check-interval 多久检查一次主从延迟、主库负载是否达到上限

—check-slave-lag 是否只检查这个从库的延迟

—max-lag 最大延迟,超过这个就等待

—max-load 最大负载,超过这个就等待

过滤选项:

—databases 只检查某些库

—tables 只检查某些表

这些过滤选项在修复不一致数据后,检查修复效果很有用。

其他选项

—resume 因某种原因中断,下次接着执行,不用从头开始

—chunk-time 每个chunk被计算的时间,一般默认为0.5秒

用法举例

PTDEBUG=1 ./pt-table-checksum --user=user --password=pass --host=10.10.10.10 --port=3306 --databases=nettedfish --tables=just_do_it --recursion-method=processlist

缺陷和注意事项

如果表没有主键或唯一索引,或者干脆没有任何索引,那么pt工具在chunk表的时候,将无所适从。不过我们已强制在建表的时候,每个表都必须有主键。

—check-binlog-format是默认选项,建议不要关闭它。pt-table-checksum工具自身产生的所有sql语句要基于语句格式同步到从库,这是由它的实现原理决定的。但是在A-B-C的级联复制结构中,如果B是行格式的复制,那么B与C的数据一致性校验就没法做了。在A上设置该sql语句为语句级并不会把set这个动作记录到binlog中,这个属性无法级联传递。

主从异构的情况下,checksum语句可能在从库上执行失败,即使是索引的不一致。例如sql语句中有force index某个索引,但是从库的表上没有这个索引,就会导致卡库。

总结

pt-table-checksum是校验主从数据不一致的最好工具。由于MySQL复制自身的缺陷,或主从切换不严谨,或备份软件bug等原因,都可能导致主从数据的不一致。不管你管不管,不一致都在那里,就看数据对你重不重要,重要的话,就定期做下检查并修复吧。

且看下回分解:用pt-table-sync修复不一致的数据

0b1331709591d260c1c78e86d0c51c18.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值