数据不一致的原因
我们平台中上线了大量的MySQL业务，但是每个MySQL业务中主从数据库之间的一致性，我们基本不可知，而且由于性能原因的考虑，我们99%左右的MySQL中的两个影响数据一致性的参数innodb_flush_log_at_trx_commit设置为1，并且sync_binlog设置为0。这样，一旦出现机器重启时，MySQL数据库的主从节点之间就会存在数据不一致性的情况。
一致性检测原理
数据不一致性出现以后，一方面会影响业务，另外一方面DBA经常会收到告警：数据库同步错误。为了解决这个问题，我们要实现平台级的数据库一致性对比功能，在平台中定期对必要的业务进行定期的一致性检测和数据修复就非常有必要性了。
所以最近研究了一下MySQL的一致性对比和修复工具：pt-table-checksum和pt-table-sync。下面分别对pt-table-checksum和pt-table-sync的原理做一下简单介绍。
pt-table-checksum的原理：
- 校验表的结构如下：
CREATE TABLE checksums (
db char(64) NOT NULL,
tbl char(64) NOT NULL,
chunk int NOT NULL,
chunk_time float NULL,
chunk_index varchar(200) NULL,
lower_boundary text NULL,
upper_boundary text NULL,
this_crc char(40) NOT NULL,
this_cnt int NOT NULL,
master_crc char(40) NULL,
master_cnt int NULL,
ts timestamp NOT NULL,
PRIMARY KEY (db, tbl, chunk),
INDEX ts_db_tbl (ts, db, tbl)
) ENGINE=InnoDB;
- 把数据进行分块，先计算第一个块的数据的校验和，并写入到校验表中的this_crc和this_cnt字段中，这条检核和的SQL语句会传递到从库，从库会收到后计算自己的SQL语句；
- 然后读取主库的中校验表的this_crc和this_cnt字段数据，生成SQL语句更新checksums表中的master_crc和master_cnt字段，从库收到SQL语句以后，会把从库中的checksums表的master_crc和master_cnt字段进行更新，这样在从库中就得到了主库的校验和以及自己的数据校验和；
- 轮询整张表，重复2,3步把所有的块计算完成；
- 通过下面这条语句就可以得出主库和从库的各个块是否一致select * from checksums where master_cnt <>this_cnt OR master_crc <> this_crc OR ISNULL(master_crc) <>ISNULL(this_crc)
pt-table-sync的原理：
- 对每一个从库，每一个表，循环进行如下校验和修复过程。
- 对每一个chunk，在校验时加上for update锁。一旦获得锁，就记录下当前主库的show master status值。
- 在从库上执行select master_pos_wait()函数，等待从库sql线程执行到show master status得到的位置。以此保证，主从上关于这个chunk的内容均不再改变。
- 对这个chunk执行checksum，然后与主库的checksum进行比较。
- 如果checksum相同，说明主从数据一致，就继续下一个chunk。
- 如果checksum不同，说明该chunk有不一致。深入chunk内部，逐行计算checksum并比较(单行的checksum的比较过程与chunk的比较过程一样，单行实际是chunk的size为1的特例)。
- 如果发现某行不一致，则标记下来。继续检测剩余行，直到这个chunk结束。
- 对找到的主从不一致的行，采用replace into语句，在主库执行一遍以生成该行全量的binlog，并同步到从库，这会以主库数据为基准来修复从库；对于主库有的行而从库没有的行，采用replace在主库上插入(必须不能是insert)；对于从库有而主库没有的行，通过在主库执行delete来删除(pt-table-sync强烈建议所有的数据修复都只在主库进行，而不建议直接修改从库数据；但是也有特例)。
- 直到修复该chunk所有不一致的行。继续检查和修复下一个chunk。
- 直到这个从库上所有的表修复结束。开始修复下一个从库。
平台一致性对比方案
有了这两个一致性对比工具，就很容易在平台中搭建一致性对比和数据修复了，我们在选择一个业务进行对比，通过指令下发就能够对业务进行一致性对比，并从平台中查询对比的进行和最终对比的结果，依据对比结果，决定是否进行数据修复。
问题出现了
测试的过程中，我们发现一旦表比较大的情况下，并且不一致的情况比较严重的情况下，会造成对比非常缓慢，最坏的情况20G的数据对比和修复需要花费6个小时，而且整个对比过程有可能会影响线上正在运行的业务。为了减少这种大表对比和修复的影响，我们必须要针对大表提出我们自己的对比和修复方案来。
解决思路
1.首先需要解决的是要找出数据库中的大表
我们可以通过指令show table status from DBNAME 获取数据库中的表的信息，可以获取到表的行数信息，就可以知道那些表是大表了。但是这条指令有可能会产生副作用，因为这条sql语句会访问information_schema下的表，访问这些表的时候，如果是innodb，这些innodb可能会自动做更新索引统计的操作，这可能会造成大量磁盘操作和缓存数据的换出，为了减少副作用，我们可以在执行show table status from DBNAME之前，先执行set global innodb_stats_on_metadata=0，来防止innodb的“顺手”操作。
2.大表对比和修复方案
大表的数据量大，所以我们想到的方案就是大数据计算平台：hadoop和spark平台。所以我们的对比过程图如下所示：
导出主从数据库表中的数据 ---> 上传到Hadoop ---> 用大数据平台对比出不同的key值 ---> 不同的key值采用pt-table-sync类似的原理一行行再次对比，过滤掉相同key ----> 剩下不同的key进行修复
通过以上手段流程就能完美的把大量的数据计算从MySQL迁移到大数据平台，剩下的少量不一致的key值，再到MySQL上比对，从而避免了对业务数据库的影响。大数据库对比有两种选择MapReduce以及Spark，相对来说Spark会比MapReduce简单很多，所以我们选择Spark，
下面简单介绍一下大概的对比方案的实施步骤：
1 导出文件
采用select * into outfile从mysql中导出要对比的表，假设我们从master中导出了一张表，导出文件为：master.txt，内容为：
1,"abc","dddddd"
2,"ef","adddd"
从slave中导出一张表，导出文件为：slave.txt，内容为：
1,"abc","tttt"
2,"ef","fffff"
2 上传文件到hdfs中
hadoop fs -copyFromLocal master.txt /
hadoop fs -copyFromLocal slave.txt /
3 采用下面的spark脚本计算不同的key值
val rddMaster = sc.textFile("/master.txt").map(x =>(x.split(",")(0), x)) // 假设第一个字段是主键
val rddSlave = sc.textFile("/slave.txt").map(x =>(x.split(",")(0), x))
val difference = rddMaster.cogroup(rddSlave).filter(x=> x._2._1 != x._2._2 )
val differenceKey = difference.keys()
differenceKey.collect
通过三面的三个步骤我们就能够得出不同的key值有哪些了。
上面的代码非常简单，只是提供一个思路，对于具体的情况肯定会复杂一些，如有多个主键的情况，依据主键数据中包含了分割符号等等情况，这里就不对这些情况进行细说了。
