假如我们生产环境复制出错?该怎么办呢?
下面提供几种办法:
1. 手工处理,补回不一致数据(可以利用主库来补数据、也可以利用binlog来补数据)
2.用开源工具来解决一致性问题
3.自己造轮子,解决一致性问题
至于如何通过手工方式来修复不一致数据,我就不一一说了,大概就是缺啥补撒把,要是大量的不一致,那么手工来搞必然会累的半死,而且也不科学,本文主要介绍一下三方工具pt-table-sync
Pt-table-sync 原理:
1. 在主库上分析表结构,把说有字段转换成varchar类型
2. 根据表上的索引,把表数据分成一个个的chunck
3. 对于每个 chunck ,把字段利用 concat_ws() 函数链接到一起,然后对这个值计算 MD 5 值,存到统计表(test库下边)
4. 由于复制关系,这个统计数据会被复制到从库,并且同样的语句也会被执行一遍
5. 到此基本的条件都具备了, 那么就开始执行对比了,具体对比过程是这样的:对于每个chunck会有个 主库的MD 5 值和备考的MD 5 值,for 每个chunck,if MD 5 值相等,则跳过;else 深入chunck ,逐行检查每行数据;
1. 那么由于时主从关系,复制必然有延迟的情况,如何保证在检查md 5 时 主从数据是一致的呢,或者说是相同数量的行呢?
这个就的深入到 p t-table-sync 在计算chunck MD 5 值的时候是如何计算的了:
主库上: 对每一个 chunk ,在校验时加上 for update 锁。一旦获得锁,就记录下当前主库的 show master status 值。
从库上 : 执行 select master_pos_wait() 函数,等待从库 sql 线程执行到 show master status 得到的位置。以此保证,主从上关于这个 chunk 的内容均不再改变。
2. 主备不一致时候,是怎么修复的呢?
对于主库有但是备库不存在的数据(或者主备不一致):那么备库会跳过,在主库上执行 replace into 操作,通过binlog复制的方式在备库进行重新应用。
对于备库有, 但主库不存在的数据:那么依然是在主库执行 delete 操作(主库本来就不存在数据, 所以这个语句对于主库来说是安全的)
1.这是一种 盲目的复制同步检查机制 ,同样的数据会在主库和备考计算,给主库备库都带来了额外的负担,同时由于复制关系,这个数据会被copy到从库,给网络带来了压力,给备库也带来了压力(一个是在应用主库传过来的数据的时候,另一个是在计算md 5 值时)
2. 由于我们的 replace into机制,那么就必须要求这个表上存在 主键或者唯一健
3. 由于在检查 chunck 的时候采用 s elect for update 那么必然会加 X 锁,如果备库延迟太大,则应用的性能会有所下降
那么我们有没有一种不盲目的方式呢?其实我们可以自己实现的,具体如何实现,我将在稍后讲到