pt-table-sync修复主从库不一致数据

一、实例演示1

模拟主从库数据不一致环境：

192.168.0.39 master库:
mysql> select * from test01.frame01;;
+----+-----------+------------------------------------------+
| id | parent_id | dsn                                      |
+----+-----------+------------------------------------------+
|  1 |         1 | 192.168.0.22,u=pt22,p=ptchecksums,P=3307 |
|  2 |         2 | 192.168.0.33,u=pt33,p=ptchecksums,P=3308 |
+----+-----------+------------------------------------------+
2 rows in set (0.00 sec)

192.168.0.39 slave库:
mysql> update frame01 set dsn=‘192.168.0.55,u=umaaa,p=ptchsyeudew,P=3310‘ where id=1;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> update frame01 set dsn=‘192.168.0.66,u=umbbb,p=ptchsyeudew,P=3311‘ where id=2;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> select * from frame01;
+----+-----------+-------------------------------------------+
| id | parent_id | dsn                                       |
+----+-----------+-------------------------------------------+
|  1 |         1 | 192.168.0.55,u=umaaa,p=ptchsyeudew,P=3310 |
|  2 |         2 | 192.168.0.66,u=umbbb,p=ptchsyeudew,P=3311 |
+----+-----------+-------------------------------------------+

pt-table-sync校验修复数据具体指令：

[[email protected] ~]#  /usr/local/percona-toolkit/bin/pt-table-sync h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=test01 --tables=frame01 --replicate=percona.checksums --print
REPLACE INTO `test01`.`frame01`(`id`, `parent_id`, `dsn`) VALUES (‘1‘, ‘1‘, ‘192.168.0.22,u=pt22,p=ptchecksums,P=3307‘) /*percona-toolkit src_db:test01 src_tbl:frame01 src_dsn:P=3306,h=192.168.0.39,p=...,u=ptsum dst_db:test01 dst_tbl:frame01 dst_dsn:P=3306,h=192.168.0.11,p=...,u=ptsum lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:176411 user:root host:kusou-es11*/;
REPLACE INTO `test01`.`frame01`(`id`, `parent_id`, `dsn`) VALUES (‘2‘, ‘2‘, ‘192.168.0.33,u=pt33,p=ptchecksums,P=3308‘) /*percona-toolkit src_db:test01 src_tbl:frame01 src_dsn:P=3306,h=192.168.0.39,p=...,u=ptsum dst_db:test01 dst_tbl:frame01 dst_dsn:P=3306,h=192.168.0.11,p=...,u=ptsum lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:176411 user:root host:kusou-es11*/;

提示： 命令末尾的--print的指令是打印出需要修复数据的命令，不执行命令。

pt-table-sync 修复主从库的表frame01数据 ，使主从库表frame01数据一致：


[[email protected] ~]#  /usr/local/percona-toolkit/bin/pt-table-sync h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=test01 --tables=frame01 --replicate=percona.checksums --execute
[[email protected] ~]#

提示： 命令末尾的 --execute 的指令是执行修复数据的指令，使master库mysql.user表和slave库的mysql.user表数据一致

pt-table-checksum 检测主从库的表frame01数据一致 （因为 DIFFS =0 ）

[[email protected] ~]#  /usr/local/percona-toolkit/bin/pt-table-checksum  h=192.168.0.39,u=ptsum,p=‘ptchecksums‘,P=3306 --databases=test01 --tables=frame01 --replicate=percona.checksums  --no-check-binlog-format --nocheck-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
06-15T13:41:47      0      0        2          0       1       0   0.316 test01.frame01

slave库查看，数据和主库一致

mysql> select * from test01.frame01;
+----+-----------+------------------------------------------+
| id | parent_id | dsn                                      |
+----+-----------+------------------------------------------+
|  1 |         1 | 192.168.0.22,u=pt22,p=ptchecksums,P=3307 |
|  2 |         2 | 192.168.0.33,u=pt33,p=ptchecksums,P=3308 |
+----+-----------+------------------------------------------+
2 rows in set (0.00 sec)

提示：需要注意的是，需要同步的表上必须要有主键或者唯一索引，否则会出错。
同时，pt-table-sync 修复数据时，会造成锁表，要在业务低峰期来修复主库的数据

对找到的主从不一致的行，采用replace into语句，在主库执行一遍以生成该行全量的binlog，并同步到从库，这会以主库数据为基准来修复从库；
对于主库有的行而从库没有的行，采用replace在主库上插入(必须不能是×××ert)；
对于从库有而主库没有的行，通过在主库执行delete来删除(pt-table-sync强烈建议所有的数据修复都只在主库进行，而不建议直接修改从库数据；但是也有特例，以后面会讲到)。

二、实例演示2

在slave库上的mysql user表上，新建一个用户 [email protected]‘192.168.0.%‘ 模拟master和slave库数据不一致

grant all on *.* to [email protected]‘192.168.0.%‘ identified by ‘DHWUOEdwerer‘;flush privileges;
[[email protected] ~]#  /usr/local/percona-toolkit/bin/pt-table-checksum  h=192.168.0.39,u=ptsum,p=‘ptchecksums‘,P=3306 --databases=mysql --replicate=percona.checksums  --no-check-binlog-format --nocheck-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
06-15T13:32:27      0      0        0          0       1       0   0.317 mysql.columns_priv
06-15T13:32:28      0      0        2          0       1       0   0.318 mysql.db
06-15T13:32:28      0      0        2          0       1       0   0.316 mysql.engine_cost
06-15T13:32:28      0      0        0          0       1       0   0.317 mysql.event
06-15T13:32:29      0      0        0          0       1       0   0.316 mysql.func
06-15T13:32:29      0      0       41          0       1       0   0.317 mysql.help_category
06-15T13:32:29      0      0      699          0       1       0   0.318 mysql.help_keyword
06-15T13:32:30      0      0     1413          0       1       0   0.319 mysql.help_relation
06-15T13:32:30      0      0      643          0       1       0   0.325 mysql.help_topic
06-15T13:32:30      0      0        0          0       1       0   0.316 mysql.ndb_binlog_index
06-15T13:32:31      0      0        0          0       1       0   0.316 mysql.plugin
06-15T13:32:31      0      1       48          0       1       0   0.317 mysql.proc
06-15T13:32:31      0      0        0          0       1       0   0.317 mysql.procs_priv
06-15T13:32:32      0      0        1          0       1       0   0.317 mysql.proxies_priv
06-15T13:32:32      0      0        6          0       1       0   0.317 mysql.server_cost
06-15T13:32:32      0      0        0          0       1       0   0.316 mysql.servers
06-15T13:32:33      0      0        2          0       1       0   0.317 mysql.tables_priv
06-15T13:32:33      0      0        0          0       1       0   0.316 mysql.time_zone
06-15T13:32:33      0      0        0          0       1       0   0.316 mysql.time_zone_leap_second
06-15T13:32:33      0      0        0          0       1       0   0.316 mysql.time_zone_name
06-15T13:32:34      0      0        0          0       1       0   0.318 mysql.time_zone_transition
06-15T13:32:34      0      0        0          0       1       0   0.317 mysql.time_zone_transition_type
**06-15T13:32:34      0      1        6          1       1       0   0.319 mysql.user**

在slave库上pt-table-sync 修复数据：

slave库上操作：

[[email protected] ~]# /usr/local/percona-toolkit/bin/pt-table-sync h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=mysql --tables=user --replicate=percona.checksums --print
Access denied for user ‘ptsum‘@‘192.168.0.%‘ to database ‘mysql‘ [for Statement "LOCK TABLES `mysql`.`user` WRITE"] at line 6172 while doing mysql.user on 192.168.0.11

报错，提示没lock tables 权限

解决办法：登录master库重新授权，添加lock tables权限

grant  update,×××ert,select,create,drop,delete,index,execute,lock tables,super,process,replication slave on *.* to [email protected]‘192.168.0.%‘ identified by ‘ptchecksums‘; flush privileges;

再次操作不在报错br/>**输出提示master库的mysql.user表和slave库的mysql.user表的数据不一致。slave库的mysql.user表多了一个用户[email protected]‘192.168.0.%‘。需要删除这个用户，才能保证主库和从库数据的一致
换句话说：
由于从库只是比主库多了一条数据，pt-table-sync将以主库以准，在主库执行一个删除操作的事件，然后slave应用此事件完成同步**

[[email protected] ~]# /usr/local/percona-toolkit/bin/pt-table-sync h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=mysql --tables=user --replicate=percona.checksums --print
DELETE FROM `mysql`.`user` WHERE `host`=‘192.168.0.%‘ AND `user`=‘qdtets‘ LIMIT 1 /*percona-toolkit src_db:mysql src_tbl:user src_dsn:P=3306,h=192.168.0.39,p=...,u=ptsum dst_db:mysql dst_tbl:user dst_dsn:P=3306,h=192.168.0.11,p=...,u=ptsum lock:1 transaction:0 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:137319 user:root host:kusou-es11*/;

提示： 命令末尾的--print的指令是打印出需要修复数据的命令，不执行命令。

使用pt-table-checksum检测mysql的user表，DIFFS =1 事实证明master和slave的mysql user表数据确实不一致：

[[email protected] ~]# /usr/local/percona-toolkit/bin/pt-table-checksum  h=192.168.0.39,u=ptsum,p=‘ptchecksums‘,P=3306 --databases=mysql --tables=user  --no-check-binlog-format --nocheck-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
06-15T09:58:37      0      1        6          1       1       0   0.318 mysql.user

执行修复命令pt-table-sync 修复master和slave的mysql user表数据：

[[email protected] ~]#  /usr/local/percona-toolkit/bin/pt-table-sync h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=mysql --tables=user --replicate=percona.checksums --execute
[[email protected] ~]#

提示： 命令末尾的 --execute 的指令是执行修复数据的指令，使master库mysql.user表和slave库的mysql.user表数据一致

slave库上检查master库的mysql.user表 和slave库的mysql.user 表数据是否一致：

[[email protected] ~]# /usr/local/percona-toolkit/bin/pt-table-checksum  h=192.168.0.39,u=ptsum,p=‘ptchecksums‘,P=3306 --databases=mysql --tables=user  --no-check-binlog-format --nocheck-replication-filters
Checking if all tables can be checksummed ...
Starting checksum ...
            TS ERRORS  DIFFS     ROWS  DIFF_ROWS  CHUNKS SKIPPED    TIME TABLE
06-15T09:46:52      0      0        6          0       1       0   0.319 mysql.user

可以看到DIFFS =0 ，说明数据已经修复完成

三、实例演示3

将master 上的所有数据同步到slave：

[[email protected] ~]# /usr/local/percona-toolkit/bin/pt-table-sync --execute  h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=mysql --tables=user h=192.168.0.11,u=ptsum,p=‘ptchecksums‘,P=3306 --no-check-slave  --print
DELETE FROM `mysql`.`user` WHERE `host`=‘10.0.0.1‘ AND `user`=‘dhrue‘ LIMIT 1 /*percona-toolkit src_db:mysql src_tbl:user src_dsn:P=3306,h=192.168.0.39,p=...,u=ptsum dst_db:mysql dst_tbl:user dst_dsn:P=3306,h=192.168.0.11,p=...,u=ptsum lock:0 transaction:0 changing_src:0 replicate:0 bidirectional:0 pid:12565 user:root host:kusou-es11*/;

将master 上的所有数据同步到slave1和slave2：


[[email protected] ~]# /usr/local/percona-toolkit/bin/pt-table-sync --execute  h=192.168.0.39,u=ptsum,p=ptchecksums,P=3306 --databases=mysql --tables=user h=192.168.0.11,u=ptsum,p=‘ptchecksums‘,P=3307    h=192.168.0.22,u=ptsum,p=‘ptchecksums‘,P=3308   --no-check-slave  --print

对pt-table-checksum和pt-table-sync这一组工具进行了最简单的测试，其实运行这一组命令不一定需要在主从结构的主库上进行，网段内的任何服务器都可以运行，前提就是安装好这套工具就好。

四、原理介绍

pt-table-checksum/pt-table-sync原理介绍可以参考如下博文：
http://blog.sina.com.cn/s/blog_a1e9c7910102vnsd.html

原文地址：https://blog.51cto.com/wujianwei/2409529

时间： 2024-10-28 18:53:27

pt-table-sync修复主从库不一致数据的相关文章

pt-table-checksum校验主从库数据库数据

pt-table-checksum校验与pt-table-sync,前者主要用于数据的校验,验证主从是否一致,后者主要用来修复数据,两者一般情况结合起来用可以修复数据不一致的问题. 一.pt-table-checksum 安装 下载工具包 的最新地址如下: https://www.percona.com/downloads/percona-toolkit/LATEST/安装pt-table-checksum 和pt-table-sync命令.需要先安装percona-toolkit 工具集 1.

实战处理mysql主从延时不一致之手动修复

前2天经常被同事反应crm后台系统和前台,经常报前后查询不一致的问题.一开始也很抓狂,从集群.日志跟踪.网络转包等方面排查,都没找到原因,后来经过和研发同事一起沟通,提出线上mysql主从数据库可能不一致导致,于是立马登陆mysql主从服务器,查看复制状态,到这很明显问题就找到. 手动修复主从延时不一致,主库完整mysqldump导出,注意用的参数.经过实践,是线上成功修复主从不一致的结果哦.还有个奇葩的问题,就是刚修复主从不一致,很快又出现,延时又拉很大.到这你是否会想到,主库有大量数据的写入

MySQL主从库为什么会出现同一条数据的某个字段不一致？

问题描述: 开发环境的MySQL用了两台节点,主从同步结构.忽然有开发同学反映说在主库insert一条数据,发现在从库没有同步,查不到这条数据.于是开始排查. 原因排查: 1.查看主从同步状态 在主库执行: show master status\G 在从库执行: show slave status\G; 发现从库同步的bin log的Position跟主库查询到的不一致,以为是同步延迟了.然后手动在主库创建了一个测试database,发现从库立即同步了,主从同步的点也是一致的. 2.排查插入字段

mysql（五）------针对主从同步的情况两个库进行数据校对及恢复

两台MySQL,发生了种种种种,导致了两个表的数据不一致,但是同步还在正常进行,后来意识到这种问题(可能之前skip啊,或者一开始搭建的时候就是不一致的状态),该如何修复呢?如果数据量小的情况可以考虑从新导数据,如果数据量很大的话,那就太要命了于是可以用percona-toolkit这个工具修复并并检查这种情况的再主备同步的时候在进行如下操作:在主库上安装pt-table-checksum安装: 1.安装软件包: # yum install perl perl-devel perl-Time-H

pt-table-checksum、pt-table-sync核对主从库一致性

一．下载并安装工具http://www.percona.com/downloads/percona-toolkit/目前最新的版本是percona-toolkit_2.2.12.tar.gz上传到服务器后,解压缩,并设置到环境变量在mysql用户的环境变量文件增加路径vi .bash_profileexport PATH=$PATH:/mysqldata/soft/percona-toolkit-2.2.12/bin 二．使用pt-table-checksum命令查找不一致的数据主要关注的列是D

关于Mysql 查询所有表的实时记录用于对比2个MySQL 库的数据是否异步

Xu言: 今天,为了研究一个MySQL主从同步开机后报错 问题,如下图 故障原因分析: 经过分析,可能是主从服务器开机顺序导致.(有待下次断电再次测试) 主从错误提示:日志读取错误的问题.解决方法:更新日志记录文件,重新主从同步. 担心主从问题过程中有数据写入,想去确认下主从库上的数据是否一致.想到了查询下数据库行数的方式. 网上查询了下 ,一般有2种: 方法一:查看当前表的记录行数 SELECT count(*) from 表名 方法二:"查看数据库中所有表的记录数"  # 这里之所

主从库延迟对项目质量的影响

最近在测试一个新的项目,原来项目是不存在主从库,和服务器集群的内容. 但新的项目进行了架构升级,随着业务的增长,这种普遍的服务器集群,读写分离等基本的架构内容一定是需要使用的. 出现的问题: A系统在购买某个产品的时候,先从产品的剩余数量中减去购买量,发送一个mq消息,前面的几个事儿作为一个事务进行提交. B系统监听到mq消息后,对用户的金额进行扣减,扣减成功,发送mq消息,一个整体的事务 A监听到B的mq后,查询购买产品的内容,并对数量进行真实的扣减. 问题处在,A系统查询产品的内容是从从库进

基于mysql5.6版本的主从库同步

系统:centos6.4 mysql版本:5.6.17 主库:192.168.31.111 从库:192.168.31.235 主库操作: 1.配置my.cnf文件开启二进制日志 log_bin = on server_id = 1 2.建立用于同步数据库的账号rep grant replication slave on *.* to 'rep'@'192.168.31.%' identified by 'redhat'; select user,host,password from mysql

MS Sql Server 中主从库的配置和使用介绍(转)

网站规模到了一定程度之后,该分的也分了,该优化的也做了优化,但是还是不能满足业务上对性能的要求:这时候我们可以考虑使用主从库. 主从库是两台服务器上的两个数据库,主库以最快的速度做增删改操作+最新数据的查询操作:从库负责查询较旧数据,做一些对实效性要求较小的分析,报表生成的工作.这样做将数据库的压力分担到两台服务器上从而保证整个系统响应的及时性. SQL Server提供了复制机制来帮我们实现主从库的机制.我们看下如何在sql server 2005中实践: 实践前需要新创建一个Test的数据库