如何验证主从数据库数据内容一致

Answer 1

用 pt-table-checksum 时，会不会影响业务性能？

实验

实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。

我们先建一对主从：

然后用 mysqlslap跑一个持续的压力：

开另外一个会话，将 master 上的 general log 打开：

然后通过 pt-table-checksum 进行一次比较：

查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：

将该线程的操作单独列出来：

操作比较多，我们一点一点来说明：

这里工具调小了 innodb 锁等待时间。使得之后的操作，只要在 innodb 上稍微有锁等待，就会马上放弃操作，对业务影响很小。

另外工具调小了 wait_timeout 时间，倒是没有特别的作用。

工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。

RR 级别是数据对比的基本要求。

工具通过一系列操作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。

接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。

之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。

以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。

工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。

总结

本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。

还是那个观点，性能测试不能相信道听途说，得通过实验去分析。

Answer 2

　　percona-toolkit-2.2.8-1.noarch.rpm有两个工具可以验证MySQL主从数据的一致性
 
安装tookkit需要一些依赖包
 
yum install perl perl-DBI perl-DBD-MySQL perl-IO-Socket-SSL perl-Time-HiRes -y

　　实验环境

　　在Master上初始化实验数据
 
create database mvbox;
 
use mvbox;

　　create table test(id int primary key,name varchar(20));

　　insert into test values(1,'a'),(2,'b'),(3,'c'),(4,'d');

　　因为主从环境已经搭建，这些数据会自动同步到Slave上。
 
在Slave从库添加一个数据，模拟主从数据不一致的场景。
 
insert into test values(5,'e');
 在Master主库执行pt-table-checksum命令。
 它会使用concat_ws函数将数据合并为一行，然后使用crc32函数生成校验码,最后将其插入percona库的checksums表中。
 
因为主从环境，这个数据会复制到Slave
 也就是说Slave的percona.checksums表，存放的是主库数据的校验码。
 所以在Slave对数据执行同样的校验,然后比对checksums表中的数据,就可以验证主从是否一致。
 
所以执行pt-table-checksum命令的帐号,至少需要有全库的只读权限和percona库的读写权限。
 
create user xx;
 
GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'xx'@'%' IDENTIFIED BY 'xx';

　　grant all privileges on percona.* TO 'xx'@'%' IDENTIFIED BY 'xx';
 
查看主从一致的情况

　　TS ：完成检查的时间。
ERRORS ：检查时候发生错误和警告的数量。
DIFFS ：0表示一致，1表示不一致。当指定--no-replicate-check时，会一直为0，当指定--replicate-check-only会显示不同的信息。
ROWS ：表的行数。
CHUNKS ：被划分到表中的块的数目。
SKIPPED ：由于错误或警告或过大，则跳过块的数目。
TIME ：执行的时间。
TABLE ：被检查的表名。
 常用参数
 
--nocheck-replication-filters ：不检查复制过滤器，建议启用。后面可以用--databases来指定需要检查的数据库。
--no-check-binlog-format : 不检查复制的binlog模式，要是binlog模式是ROW，则会报错。
--replicate-check-only :只显示不同步的信息。
--replicate= ：把checksum的信息写入到指定表中，建议直接写到被检查的数据库当中。 
--databases= ：指定需要被检查的数据库，多个则用逗号隔开。
--tables= ：指定需要被检查的表，多个用逗号隔开
h=127.0.0.1 ：Master的地址
u=root ：用户名
p=123456：密码
P=3306 ：端口
 可以看到这个工具已经检测到了主从不一致的情况。
 
如果发生不一致，可以使用pt-table-sync命令修复。
 需要注意的是这个命令需要在Slave从库执行。
 使用print参数，他会在屏幕显示修复的SQL语句。然后可以手工确认并执行。

　　也可以通过这个命令自动执行，不过这样会修改从库的数据，感觉不是太安全。
 

　　需要特别注意的是这两个命令执行的过程中，会对表上共享锁，所以生产环境要慎重选择执行时间。