MySQL主从复制是基于Binlog的逻辑复制，主从数据一致性会因为MySQL的Bug或者人为误操作等原因产生不一致，而这种不一致又因为逻辑复制的原因，可能隐藏了很久都不会被发现，只有在更新不一致的数据，导致主从复制中断，或者读写分离，业务读从库，发现数据不对时，才能被发现。
针对MySQL可能产生的数据不一致问题，Percona公司提供了两个工具，用于MySQL数据一致性的校验与修复。
-
pt-table-checksum
-
pt-table-sync
1. pt-table-checksum
用法：
pt-table-checksum –recursion-method=”processlist” –nocheck-binlog-format –nocheck-replication-filters –databases=db h=127.0.0.1,u=admin,p=123456
–databases 指定校验的数据库名称
–tables=tb,tb1，也可以指定校验某个表或某几个表，
h,u,p分别为主 库ip，mysql用户名和密码
[root@localhost opt]# pt-table-checksum –recursion-method=”processlist” –nocheck-binlog-format –nocheck-replication-filters –databases=db h=127.0.0.1,u=admin,p=123456
Checking if all tables can be checksummed …
Starting checksum …
TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE
02-27T10:09:36 0 1 16 0 1 0 0.351 db.tb
02-27T10:09:37 0 0 3 0 1 0 0.312 db.tb1
02-27T10:09:37 0 0 0 0 1 0 0.312 db.tb10
02-27T10:09:37 0 0 1 0 1 0 0.309 db.tb3
02-27T10:09:38 0 0 1 0 1 0 0.310 db.tb4
02-27T10:09:38 0 0 1 0 1 0 0.310 db.tb5
02-27T10:09:38 0 0 1 0 1 0 0.326 db.tb6
02-27T10:09:38 0 0 1 0 1 0 0.310 db.tb7
02-27T10:09:39 0 0 0 0 1 0 0.310 db.tb8
02-27T10:09:39 0 0 0 0 1 0 0.310 db.tb9
以上输出信息中，DIFFS列如果不为0，说明该表有数据不一致。如果有多个从库，无法判断是哪个从库数据不一致，需要连接到每个从库，查询percona.checksums 表来判断。
select * from percona.checksums where this_crc != master_crc;
2. pt-table-sync
修复原则：
数据永远以主库为准，来修复从库。
用法：
pt-table-sync –databases=db h=127.0.0.1,u=sndsadmin,p=123456 –replicate=percona.checksums –print
h=127.0.0.1 主库IP
–print 只打印修复SQL
–execute 执行修复
pt-taable_sync使用限制：
修复数据不一致时，表必须有主键或唯一键，否则报错，如下：
Can’t make changes on the master because no unique index exists at /usr/bin/pt-table-sync line 10858. while doing db.tb on 127.0.0.1