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