percona-toolkit工具检查mysql复制一致性及修复不一致性

2eew

一、pt-table-checksum检查主从库数据的一致性
  pt-table-checksum在MASTER上校验指定库、表，将结果存在一个库表里，复制进程将检验sql传递到slave上再执行一次。通过比较M/S的检验值确定数据是否一致。利用主从复制做检验，不需要在检验期间对主从数据库同时锁表，可以控制校验的数据和速度，不影响到正常服务。
安装：
1、安装依赖包yum perl perl-devel perl-DBI perl-DBD-MySQL perl-TermReadKey perl-IO-Socket-SSL perl-Time-HiRes -y2、#percona-toolkit包wget 3、编译安装 tar xzvf percona-toolkit-2.2.4.tar.gz ;  cd percona-toolkit-2.2.4 ;   perl Makefile.pl && make && make install使用方法：
pt-table-checksum [OPTIONS] [DSN]
pt-table-checksum：在主<Master>上通过执行校验的查询对复制的一致性进行检查，对比主从的校验值，从而产生结果。DSN指向的是主的地址，该工具的退出状态不为零，如果发现有任何差别，或者如果出现任何警告或错误，更多信息请见官网。

1、不指定任何参数，会直接对本地的所有数据库的表进行检查：
pt-table-checksum –S /tmp/mysqld.sock u=root,p=123456实验环境：




2、在Master上初始化实验数据

1 2 3 4 5 6

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上。

3、在Slave从库添加一个数据，模拟主从数据不一致的场景。
注意，这里模拟的是slave数据比master数据多

1 2 3

insert into test values(5,'e'); insert into test values(6,'f');

在Master主库执行pt-table-checksum命令，因为主从环境，这个数据会复制到Slave
也就是说Slave的percona.checksums表，存放的是主库数据的校验码。

所以在Slave对数据执行同样的校验,然后比对checksums表中的数据,就可以验证主从是否一致。

4、注意：

1 2 3 4 5

a、  根据测试，需要一个即能登录主库，也能登录从库，而且还能同步数据库的账号； b、  只能指定一个host，必须为主库的IP； c、  在检查时会向表加S锁； d、  运行之前需要从库的同步IO和SQL进程是YES状态。 5、所以执行pt-table-checksum命令的帐号,至少需要有全库的只读权限和percona库的读写权限。

1	GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO ‘per’@'192.168.2.%’ IDENTIFIED BY ‘p4ssword’;

6,查询主从库的数据
#主库：mysql> use mvboxReading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -ADatabase changedmysql> select * from test;+----+------+| id | name |+----+------+|  1 | a    ||  2 | b    ||  3 | c    ||  4 | d    |+----+------+4 rows in set (0.00 sec)#从库：mysql> select * from test;+----+------+| id | name |+----+------+|  1 | a    ||  2 | b    ||  3 | c    ||  4 | d    ||  5 | e    ||  6 | f    |+----+------+6 rows in set (0.00 sec)7、执行检测（MASTER上）：


参数说明：

1 2 3 4 5 6 7 8

TS            ：完成检查的时间。 ERRORS             ：检查时候发生错误和警告的数量。 DIFFS              ：0表示一致，1表示不一致。当指定--no-replicate-check时，会一直为0，当指定--replicate-check-only会显示不同的信息。 ROWS               ：表的行数。 CHUNKS             ：被划分到表中的块的数目。 SKIPPED            ：由于错误或警告或过大，则跳过块的数目。 TIME              ：执行的时间。 TABLE              ：被检查的表名。

参数意义：

1 2 3 4 5 6 7 8 9 10 11

-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                    ：端口 更多的参数请见官网，上面指出来的是常用的，对该场景够用的参数

通过DIFFS是1可以看出主从的表数据不一致。
通过查看从库上的test.checksums表可以看到主从库的检验信息。
mysql>  use percona;mysql> select * from checksums\G;*************************** 1. row ***************************            db: mvbox           tbl: test         chunk: 1    chunk_time: 0.001801   chunk_index: NULLlower_boundary: NULLupper_boundary: NULL      this_crc: b76fca95             #从的校验值      this_cnt: 6                  #从的行数      master_crc: f2890e1c             #主的校验值      master_cnt: 4                 #主的行数      ts: 2016-01-15 10:03:311 row in set (0.00 sec)通过上面的 this_crc <>, master_crc 更能清楚的看出他们的不一致了，通过chunk知道是这个张表的哪个块上的记录出现不一致。
要是主的binlog模式是Row 则会报错：

1 2 3

Replica db2 has binlog_format ROW which could cause pt-table-checksum to break replication. Please read "Replicas using row-based replication" in the LIMITATIONS section of the tool's documentation. If you understand the risks, specify --no-check-binlog-format to disable this check.

从错误信息得出，要是不改binlog模式的话，则在执行上面的命令时候要指定：--no-check-binlog-format，即：


数据不一致的SLAVE和表都找出来了，下面就用pt-table-sync来修补数据。


二、pt-table-sync修复从库不一致的数据
使用方法：

1	pt-table-sync [OPTIONS] DSN [DSN]

pt-table-sync: 高效的同步MySQL表之间的数据，他可以做单向和双向同步的表数据。他可以同步单个表，也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。

继续上面的复制环境，主和从的test表数据不一致，需要修复

#先MASTER的IP，再SLAVE的IP，以下是master执行结果


#下面是在slave执行的结果

建议还是用--print 打印出来的好，这样就可以知道那些数据有问题，可以人为的干预下。不然直接执行了，出现问题之后更不好处理。总之还是在处理之前做好数据的备份工作。


参数的意义：

1 2 3 4 5 6 7 8 9 10

--replicate=  ：指定通过pt-table-checksum得到的表，这2个工具差不多都会一直用。 --databases=  : 指定执行同步的数据库，多个用逗号隔开。 --tables=    ：指定执行同步的表，多个用逗号隔开。 --sync-to-master ：指定一个DSN，即从的IP，他会通过show processlist或show slave status 去自动的找主。 h=127.0.0.1     ：服务器地址，命令里有2个ip，第一次出现的是M的地址，第2次是Slave的地址。 u=root        ：帐号。 p=123456       ：密码。 --print        ：打印，但不执行命令。 --execute      ：执行命令。 更多的参数请见官网，上面指出来的是常用的，对该场景够用的参数。

开始修复数据：
先看下slave数据


执行修复命令，此时在slave进行执行的操作

再次查看slave数据

此时，表明数据已经同步完成

注意：要是表中没有唯一索引或则主键则会报错：

1	Can't make changes on the master because no unique index exists at /usr/local/bin/pt-table-sync line 10591.

补充：
由于正式环境都是主从没有延迟，一致性正常、所以模拟了以上做法，反过来 原理相同、
要是主库有的数据，而从库没有，那这个数据怎么处理？会主动添加SLAVE少了数据， 修复SLAVE缺失数据的SQL语句。

如果在shell窗口不想显示输入密码则可以添加：--ask-pass 参数，如：
[iyunv@mysql-slave ~]#  pt-table-sync --print --ask-pass --sync-to-master h=192.168.2.23,u=root,P=3306 --databases mvbox --tables testEnter password for 192.168.2.23:如果使用--ask-pass，报错：

1	Cannot read response; is Term::ReadKey installed? Can't locate Term/ReadKey.pm in @INC

安装Term/ReadKey.pm模块：
[iyunv@mysql-slave ~]# perl -MCPAN -e "shell"cpan[1]> install Term::ReadKey

总结：
  该工具执行检查表动作，检查连接的帐号需要有很高的权限，在一般权限上需要加SELECT, PROCESS, SUPER, REPLICATION SLAVE等权限。pt-table-checksm 配合pt-table-sync使用，在执行pt-table-sync数据同步之前，一定要执行pt-table-checksm命令检查。