pt-table-checksum校验mysql数据一致性
2015-12-02 10:19
369 查看
主从数据的一致性校验是个头疼的问题,偶尔被业务投诉主从数据不一致,或者几个从库之间的数据不一致,这会令人沮丧。通常我们仅有一种办法,热备主库,然后替换掉所有的从库。这不仅代价非常大,而且类似治标不治本的方案,让人十分不安。因此我们需要合适的工具,至少帮我们回答下面三个问题:
是从库延迟导致了用户看到的数据不一致,还是真的主从数据就不一致?
如果不一致,这个比例究竟多大?
下次还会出现吗?
回答清楚这几个问题,有助于我们决定是否修复,以及修复的方式,还可以帮我们找出不一致的数据,进而定位问题根源。而percona的pt-table-checksum正是我们想要的。
pt-table-checksum是著名的 percona-toolkit 工具集的工具之一。它通过在主库执行基于statement的sql语句来生成主库数据块的checksum,把相同的sql语句传递到从库,并在从库上计算相同数据块的checksum,最后,比较主从库上相同数据块的checksum值,由此判断主从数据是否一致。这种校验是分表进行的,在每个表内部又是分块进行的,而且pt工具本身提供了非常多的限流选项,因此对线上服务的冲击较小。
pt工具先检查表的结构,并获取每一列的数据类型,把所有数据类型都转化为字符串,然后用 concat_ws() 函数进行连接,由此计算出该行的checksum值。checksum默认采用crc32,你可以自己定义效率更高的udf。
如果一行一行的计算checksum再去和从库比较,那么效率会非常低下。pt工具选择智能分析表上的索引,然后把表的数据split成一个个chunk,计算的时候也是以chunk为单位。因此引入了聚合函数 BIT_XOR() 。它的功能可以理解为把这个chunk内的所有行的数据拼接起来,再计算crc32的值,就得到这个chunk的checksum值。sql语句如下:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/7a6dd5fef2e1f04599bd200a0ef323ab.png)
这其中还有count(*),用来计算chunk包含的行数。每一次对chunk进行checksum后,pt工具都会对耗时进行统计分析,并智能调整下一个chunk的大小,避免chunk太大对线上造成影响,同时也要避免chunk太小而效率低下。
当pt工具在计算主库上某chunk的checksum时,主库可能还在更新,同时从库可能延迟使得relay-log中还有与这个chunk数据相关的更新,那该怎么保证主库与从库计算的是”同一份”数据?答案是加for update当前读锁,这保证了主库的某个chunk内部数据的一致性。否则,1000个人chekcusm同样的1000行数据,可能得到1000个不同的结果,你无法避开mvcc的干扰!获得for update锁后,pt工具开始计算chunk的checksum值,并把计算结果保存到pt工具自建的结果表中(采用replace
into select的方式),然后释放锁。该语句最终会传递到从库并执行相同的计算逻辑。
有了上面关键的几点说明,我们再来看看pt工具的内部工作过程,如下图:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/3aa725ec543a7a6306353e1fa237914c.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语句即可看到是否有主从不一致发生:
–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秒
如果表没有主键或唯一索引,或者干脆没有任何索引,那么pt工具在chunk表的时候,将无所适从。不过我们已强制在建表的时候,每个表都必须有主键。
–check-binlog-format是默认选项,建议不要关闭它。pt-table-checksum工具自身产生的所有sql语句要基于语句格式同步到从库,这是由它的实现原理决定的。但是在A-B-C的级联复制结构中,如果B是行格式的复制,那么B与C的数据一致性校验就没法做了。在A上设置该sql语句为语句级并不会把set这个动作记录到binlog中,这个属性无法级联传递。
主从异构的情况下,checksum语句可能在从库上执行失败,即使是索引的不一致。例如sql语句中有force index某个索引,但是从库的表上没有这个索引,就会导致卡库。
是从库延迟导致了用户看到的数据不一致,还是真的主从数据就不一致?
如果不一致,这个比例究竟多大?
下次还会出现吗?
回答清楚这几个问题,有助于我们决定是否修复,以及修复的方式,还可以帮我们找出不一致的数据,进而定位问题根源。而percona的pt-table-checksum正是我们想要的。
pt-table-checksum简介
pt-table-checksum是著名的 percona-toolkit 工具集的工具之一。它通过在主库执行基于statement的sql语句来生成主库数据块的checksum,把相同的sql语句传递到从库,并在从库上计算相同数据块的checksum,最后,比较主从库上相同数据块的checksum值,由此判断主从数据是否一致。这种校验是分表进行的,在每个表内部又是分块进行的,而且pt工具本身提供了非常多的限流选项,因此对线上服务的冲击较小。
checksum计算原理
1. 单行数据checksum值的计算
pt工具先检查表的结构,并获取每一列的数据类型,把所有数据类型都转化为字符串,然后用 concat_ws() 函数进行连接,由此计算出该行的checksum值。checksum默认采用crc32,你可以自己定义效率更高的udf。
2. 数据块checksum值的计算
如果一行一行的计算checksum再去和从库比较,那么效率会非常低下。pt工具选择智能分析表上的索引,然后把表的数据split成一个个chunk,计算的时候也是以chunk为单位。因此引入了聚合函数 BIT_XOR() 。它的功能可以理解为把这个chunk内的所有行的数据拼接起来,再计算crc32的值,就得到这个chunk的checksum值。sql语句如下:![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/7a6dd5fef2e1f04599bd200a0ef323ab.png)
这其中还有count(*),用来计算chunk包含的行数。每一次对chunk进行checksum后,pt工具都会对耗时进行统计分析,并智能调整下一个chunk的大小,避免chunk太大对线上造成影响,同时也要避免chunk太小而效率低下。
3. 一致性如何保证
当pt工具在计算主库上某chunk的checksum时,主库可能还在更新,同时从库可能延迟使得relay-log中还有与这个chunk数据相关的更新,那该怎么保证主库与从库计算的是”同一份”数据?答案是加for update当前读锁,这保证了主库的某个chunk内部数据的一致性。否则,1000个人chekcusm同样的1000行数据,可能得到1000个不同的结果,你无法避开mvcc的干扰!获得for update锁后,pt工具开始计算chunk的checksum值,并把计算结果保存到pt工具自建的结果表中(采用replaceinto select的方式),然后释放锁。该语句最终会传递到从库并执行相同的计算逻辑。
内部工作过程
有了上面关键的几点说明,我们再来看看pt工具的内部工作过程,如下图:![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/3aa725ec543a7a6306353e1fa237914c.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某个索引,但是从库的表上没有这个索引,就会导致卡库。
相关文章推荐
- mysql 虚拟列
- mysql线上安装部署
- mysql 一条sql完成saveOrUpdate 存在即更新
- MySQL5.5不支持partition查找
- Mysql 初学常见命令
- Mysql 分区 分表相关总结之方案选择
- [实战]MVC5+EF6+MySql企业网盘实战(18)——文件上传,下载,修改
- MySQL如何记录binlog(转)
- Mysql中文乱码,修改字符集
- Mysql几种索引类型的区别及适用情况
- 删除mysql服务
- mysql更改root密码
- mysql学习(1)
- mysql数据库学习
- MySQL查询优化处理
- 启动mysql错误on Mac
- mysql中去除换行以及回车
- 高性能mysql之schema与数据类型优化
- 为IntelliJ IDEA安装MySQL驱动
- com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'itcastoa.user' doesn't exist