1. checksum table.
checksum table 会对表一行一行进行计算,直到计算出最终的 checksum 结果。
比如对表 n4 进行校验(记录数 157W,大小为 4G)
我自己笔记本上的测试结果,速度挺快。
不过checksum的限制比较多。罗列如下,
A、不能对视图进行校验。
B、字段顺序不同,校验结果也会不一致。
C、CHAR(100) 和 VARCHAR(100) 存储相同的字符,校验结果也会不一致。
D、在执行 checksum 同时,会对表所有行加共享读锁。
E、还有就是 MySQL 版本不同,有可能校验结果不一致。比如手册上说的, MySQL 5.6.5 之后的版本对时间类型的存储格式有变化,导致校验结果不一致。
那 checksum 的 限制这么多,我们是不是有其方法来突破所有限制呢? 比如说可以模拟 checksum table 的原理来手工计算。
2. 自己计算 checksum 值。
这里用了 MySQL 自身的几个特性:session 变量;通用表达式;窗口函数以及 MySQL 的 concat_ws 函数。实现非常简单。
比如我们用 sha 函数来计算校验值。
如果在 MySQL 老版本运行,可以利用 MySQL 的黑洞引擎,改下 SQL 如下:
对于表要计算校验数据一致性的需求,首选第二种自己写 SQL 的方法。
很多时候需要把一个从库提升为主库,但对从库和主库的数据一致性不敢保证,这时我们就可以利用 pt-table-checksum来检查主库数据的一致性,如果存在不一致的数据,我们可以利用pt-table-sync来修复这些不一致的数据。在主(master)上通过执行校验的查询对复制的一致性进行检查,对比主从的校验值,从而产生结果。
下面通过实际的例子来解释该工具如何使用:
主库(10.8.23.209)数据:
从库(10.8.23.208)数据:
从库(10.8.23.210)数据:
很明显主备数据不一致,我们使用工具来检测下:
校验命令参数解释:
校验结果字段解释:
好了,命令以及常用参数都介绍了,一起解释下上面执行的效果,通过DIFFS 是1 就可以看出主从的表数据不一致。怎么不一致呢? 通过指定—replicate=test.checksums 参数,就说明把检查信息都写到了checksums表中。
进入备库(10.8.23.208)中查看checksums表的信息:
进入备库(10.8.23.210)中查看checksums表的信息:
通过上面找到了这些不一致的数据,如何修复呢?利用另外一个工具 pt-table-sync。
高效的同步MySQL表之间的数据,他可以做单向和双向同步的表数据。他可以同步单个表,也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。接着上面的复制情况,主库和从库的aaa表数据不一致,需要修复。
参数解释:
命令介绍完了,一起解释下执行的效果:通过(--print)打印出来了修复数据的sql语句,可以手动的去从行执行,让他们数据保持一致性。那能否直接执行?当然可以,通过(--execute)
没发现任何异常,然后检查主从数据的一致性:
主库(10.8.23.209)数据:
从库(10.8.23.208)数据:
从库(10.8.23.210)数据:
OK,数据已经保持一致了。
不过建议还是--print 打印出来的好,这样就可以知道那些数据有问题,可以人为的干预下。
不然直接执行了,出现问题之后不好处理。总之还是在处理之前做好数据的备份工作。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)