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


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

 

 

1、pt-table-checksum检查主从库数据的一致性mysql

  pt-table-checksum在MASTER上校验指定库、表,将结果存在一个库表里,复制进程将检验sql传递到slave上再执行一次。经过比较M/S的检验值肯定数据是否一致。利用主从复制作检验,不须要在检验期间对主从数据库同时锁表,能够控制校验的数据和速度,不影响到正常服务。sql

安装:shell

一、安装依赖包
yum  install  perl perl-devel perl-DBI perl-DBD-MySQL perl-TermReadKey perl-IO-Socket-SSL 
perl-Time-HiRes -y

二、#percona-toolkit包
wget 
三、编译安装
 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指向的是主的地址,该工具的退出状态不为零,若是发现有任何差异,或者若是出现任何警告或错误,更多信息请见官网。ide

 

一、不指定任何参数,会直接对本地的全部数据库的表进行检查:工具

pt-table-checksum –S /tmp/mysqld.sock u=root,p=123456

实验环境: 测试

wKioL1aYTXHgZhlFAAASFlqX2hE478.png




二、在Master上初始化实验数据ui

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从库添加一个数据,模拟主从数据不一致的场景。this

注意,这里模拟的是slave数据比master数据多

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

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


在Master主库执行pt-table-checksum命令,由于主从环境,这个数据会复制到Slave

也就是说Slave的percona.checksums表,存放的是主库数据的校验码。

因此在Slave对数据执行一样的校验,而后比对checksums表中的数据,就能够验证主从是否一致。


四、注意:

a、  根据测试,须要一个即能登陆主库,也能登陆从库,并且还能同步数据库的帐号;
b、  只能指定一个host,必须为主库的IP;
c、  在检查时会向表加S锁;
d、  运行以前须要从库的同步IO和SQL进程是YES状态。
五、因此执行pt-table-checksum命令的账号,至少须要有全库的只读权限和percona库的读写权限。
GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO ‘per’@'192.168.2.%’ IDENTIFIED BY ‘p4ssword’;


6,查询主从库的数据

#主库:
mysql> use mvbox
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> 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)
七、执行检测(MASTER上):

wKioL1aYVyKQjqShAAA8jQV29HY492.png 


参数说明:

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


 

经过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: NULL
lower_boundary: NULL
upper_boundary: NULL
      this_crc: b76fca95             #从的校验值
      this_cnt: 6                  #从的行数
      master_crc: f2890e1c             #主的校验值
      master_cnt: 4                 #主的行数
      ts: 2016-01-15 10:03:31
1 row in set (0.00 sec)

经过上面的 this_crc <>, master_crc 更能清楚的看出他们的不一致了,经过chunk知道是这个张表的哪一个块上的记录出现不一致。

要是主的binlog模式是Row 则会报错:

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,即:

 

wKiom1aYV7zzqXYgAABENjSpSjU162.png

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

2、pt-table-sync修复从库不一致的数据

使用方法:

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

 

pt-table-sync: 高效的同步MySQL表之间的数据,他能够作单向和双向同步的表数据。他能够同步单个表,也能够同步整个库。它不一样步表结构、索引、或任何其余模式对象。因此在修复一致性以前须要保证他们表存在。

 

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


#先MASTER的IP,再SLAVE的IP,如下是master执行结果

wKioL1aYWI3TY-3mAACF8SKfhPI680.png


#下面是在slave执行的结果

wKioL1aYW2qQODUsAACF3SCk2N0700.png

建议仍是用--print 打印出来的好,这样就能够知道那些数据有问题,能够人为的干预下。否则直接执行了,出现问题以后更很差处理。总之仍是在处理以前作好数据的备份工做。


参数的意义:

--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数据

wKiom1aYXXWRfPI8AAAdiubttVw665.png

执行修复命令,此时在slave进行执行的操做

wKioL1aYXdKwBIBbAAAbPajT1Fw214.png

再次查看slave数据

wKiom1aYXeKQKkAvAAA93mChx2o747.png

此时,代表数据已经同步完成


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

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 参数,如:

[root@mysql-slave ~]#  pt-table-sync --print --ask-pass --sync-to-master h=192.168.2.23,u=root,P=3306 --databases mvbox --tables test
Enter password for 192.168.2.23:

若是使用--ask-pass,报错:

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

安装Term/ReadKey.pm模块:

[root@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命令检查。

相关文章
相关标签/搜索