假如我们生产环境复制出错？该怎么办呢？

下面提供几种办法：

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 锁，如果备库延迟太大，则应用的性能会有所下降

那么我们有没有一种不盲目的方式呢？其实我们可以自己实现的，具体如何实现，我将在稍后讲到