percona-toolkit主从同步整理（MySQL）

　　前言：MYSQL主从同步架构是目前使用最多的数据库架构之一，尤其是负载比较大的网站，因此对于主从同步的管理也就显得非常重要。而数据作为软件的核心部分，对于其有效的管理显得更为重要。随着时间的推移，软件出现故障的次数增加，很有可能造成主从数据的不一致。而要解决这个问题，就是这篇文章的目的。

 

---

 

　　一、PT工具介绍

　　　pt-table-checksum是percona-toolkit系列工具中的一个， 可以用来检测主、 从数据库中数据的一致性。其原理是在主库上运行， 对同步的表进行checksum， 记录下来。 然后对比主从中各个表的checksum是否一致， 从而判断数据是否一致。检测过程中以块为单位， 对于大的表可以区分为多个块， 从而避免锁表（ 根据唯一索引将表切分为块）检测时会自动判断复制延迟、 master的负载， 超过阀值后会自动将检测暂停。

　　　pt-table-sync，顾名思义，它用来修复多个实例之间数据的不一致。它可以让主从的数据修复到最终一致，也可以使通过应用双写或多写的多个不相关的数据库实例修复到一致。同时它还内部集成了pt-table-checksum的校验功能，可以一边校验一边修复，也可以基于pt-table-checksum的计算结果来进行修复。

 

　　二、安装percona-toolkit工具包

　　　2.1. 安装依赖包（PT工具是使用Perl语言编写和执行的，所以需要系统中有Perl环境）

　　　　　检验是否已经安装有依赖包：

　　　　　rpm -qa perl-DBI perl-DBD-MySQL perl-Time-HiRes perl-IO-Socket-SSL

　　　　　若没有，则进行安装：

　　　　　yum install perl perl-devel perl-Time-HiRes perl-DBI perl-DBD-MySQ

　　　2.2.安装percona-toolkit工具包

　　　　　wget http://www.percona.com/get/percona-toolkit.tar.gz

　　　　　tar zxf percona-toolkit-2.2.13.tar.gz

　　　　　cd percona-toolkit-2.2.13

　　　　　perl Makefile.PL

　　　　　make && make install

              

　　

　　三、在主库创建用户并授权

　　　　3.1. 授权用户

　　　　GRANT UPDATE,INSERT,DELETE,SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'checksums'@'主库地址' identified by 'checksums';
　　　　GRANT ALL ON pt.* TO 'checksums'@'主库地址' IDENTIFIED BY 'checksums';

　　　　3.2. 创建pt用到的库和表

　　　　Create database pt CHARACTER SET utf8;
　　　　use pt;
　　　　CREATE TABLE IF NOT EXISTS 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 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
　　　　PRIMARY KEY (db, tbl, chunk),
　　　　INDEX ts_db_tbl (ts, db, tbl)
　　　　) ENGINE=InnoDB;

　　　　注意：如果在后续消除差异的步骤中出现“Access denied ...”是由于2.1授权用户的权限不够，将对应的权限授予即可。

　　四、进行主从不一致校验（本步骤在生产环境中可以定时/不定时进行）

　　　　4.1. 在主库机器执行（多个数据库名用英文逗号隔开）

 　　pt-table-checksum --nocheck-binlog-format --nocheck-plan --no-check-slave-tables --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --databases 数据库名 -u'checksums' -p'checksums' -h主库地址;

　　　　 参数描述：

　　　　　　#-h -u -p -P -S -d 连接信息

　　　　　　#--nocheck-replication-filters 检测中忽略mysql 配置参数binlog_ignore_db等。

　　　　　　#--nocheck-binlog-format 不检测日志格式

　　　　　　#--replicate 指定checksum 存储的db和表， 如test.checksum

　　　　　　# --chunk-size， --chunk-size-limit 用于指定检测块的大小。 可控性更强

　　　　　　# --ignore-databases/tables/column 跳出指定元素的过滤

　　　　　　# --lock-wait-timeout innodb 锁的超时设定， 默认为1

　　　　　　# --max-load 设置最大并发连接数

　　　　　　# --replicate-check-only 只输出数据不一致的信息。

　　　　　　# --help 有这个就行了， 以及其他的详见文档。

　　　　备注：--no-check-binlog-format 忽略检查binlog格式，否则会报错，默认会去检查statement模式

 

           

　　　　 字段描述：

　　　　　　TS ：完成检查的时间。

　　　　　　ERRORS ：检查时候发生错误和警告的数量。

　　　　　　DIFFS ：0表示一致，1表示不一致。当指定--no-replicate-check时，会一直为0，当指定--replicate-check-only会显示不同的信息。

　　　　　　ROWS ：表的行数。

　　　　　　CHUNKS ：被划分到表中的块的数目。

　　　　　　SKIPPED ：由于错误或警告或过大，则跳过块的数目。

　　　　　　TIME ：执行的时间。

　　　　　　TABLE ：被检查的表名。

　　　　

　　　　如果出现 Replica 2013-20160414EX is stopped. Waiting. 说明在从库进行同步时出错了，请解决错误后再继续

　　　　

　　　　

　　　　解决方案：在从库数据库中执行 show slave status\G;查看错误原因，解决并重启slave（slave stop; slave start;）。然后重新进行主从不一致检测。

　　　　

　　　　4.2. 在从库查看不一致记录

　　　　　　待检测完成之后，在从库的pt.checksums 表中会记录下主从不一致的表，根据得到的表进行第四步。　　　　

　　　　use pt;
　　　　select db, tbl, sum(this_cnt) as total_rows, count(*) as chunks from checksums where ( master_cnt <> this_cnt OR master_crc <> this_crc OR isnull(master_crc) <> isnull(this_crc) ) group by db, tbl; 

　   　

　五、在主库消除差异-人为干预slave方式

　　　　5.1. 采用人为干预slave方式进行主从差异消除。

　　　　　　本操作在主库机器执行，执行结果会将不一致的记录生成sql脚本，之后将脚本在从库数据库执行即可。

　　　　

　　　　pt-table-sync --print --sync-to-master h=从库地址,P=3306,u=checksums,p='checksums' --databases=数据库名 --tables=表名

 

　　　　

　　　　5.2. 得到脚本，并在从库执行

　　　　　　可以将5.1的结果输出到文件，以数据库命名“数据库名.sql”，然后一起打包，上传至从库服务器执行。

　　　

　六、检查是否还有差异（主库机器执行）　　　　

　　　　pt-table-checksum --nocheck-binlog-format --nocheck-plan --no-check-slave-tables --nocheck-replication-filters --replicate=pt.checksums --set-vars innodb_lock_wait_timeout=120 --databases 数据库名 -u'checksums' -p'checksums' -h主库地址;

 

　　　　若结果中DIFFS一栏全部为0，并且在从库查看不一致记录为空，则说明主从同步成功。

　　

---

　　注意事项（摘录）：

　　　　1.采用replace into来修复主从不一致，必须保证被replace的表上有主键或唯一键，否则replace into退化成insert into，起不到修复的效果。这种情况下pt-table-sync会采用其他校验和修复算法，但是效率非常低，例如对所有列的group by然后求count(*)(表一定要有主键！)。

 

　　　　2.主从数据不一致需要通过replace into来修复，该sql语句必须是语句级。pt-table-sync会把它发起的所有sql语句都设置为statement格式，而不管全局的binlog_format值。这在级联A-B-C结构中，也会遇到pt-table-checksum曾经遇到的问题，引起行格式的中继库的从库卡库是必然。不过pt-table-sync默认会无限递归的对从库的binlog格式进行检查并警告。

 

　　　　3.由于pt-table-sync每次只能修复一个表，所以如果修复的是父表，则可能导致子表数据连带被修复，这可能会修复一个不一致而引入另一个不一致；如果表上有触发器，也可能遇到同样问题。所以在有触发器和主外键约束的情况下要慎用。pt-table-sync工具同样也不欢迎主从异构的结构。pt-table-sync工具默认会进行先决条件的检查。

 

　　　　4.pt-table-sync在修复过程中不能容忍从库延迟，这正好与pt-table-checksum相反。如果从库延迟太多，pt-table-sync会长期持有对chunk的for update锁，然 后等待从库的master_pos_wait执行完毕或超时。从库延迟越大，等待过程就越长，主库加锁的时间就越长，对线上影响就越大。因此要严格设置max-lag。

 

　　　　5.对从库数据的修复通常是在主库执行sql来同步到从库。因此，在有多个从库时，修复某个从库的数据实际会把修复语句同步到所有从库。数据修复的代价取决于从库与主库不一致的程度，如果某从库数据与主库非常不一致，举例说，这个从库只有表结构，那么需要把主库的所有数据重新灌一遍，然后通过binlog同步，同时会传递到所有从库。这会给线上带来很大压力，甚至拖垮集群。正确的做法是，先用pt-table-checksum校验一遍，确定不一致的程度：如果不同步的很少，用pt-table-sync直接修复；否则，用备份先替换它，然后用pt-table-sync修复。 说明： 这实际提供了一种对myisam备份的思路：如果仅有一个myisam的主库，要为其增加从库，则可以：先mysqldump出表结构到从库上，然后启动同步，然后用pt-table-sync来修复数据。

 

转载于:https://www.cnblogs.com/nickhan/p/6635791.html