MySQL主从数据一致性问题修复
MySQL主从数据一致性问题修复
前面，我们使用pt-table-checksum 可以检测出主从数据是否一致的问题。发现问题后，我们怎么解决这些问题，也是我们必须要会的技能。
修复主从数据一致性问题，我们使用pt-table-sync工具，和pt-table-checksum一样，都需要提前安装percona-tools工具包。怎么安装，我这里就不说了，请看我之前的文章。
下面我们来演示一下主从数据一致性问题修复
1.环境介绍
| IP | 端口 | 角色 |
|---|---|---|
| 192.168.199.230 | 3306 | Master |
| 192.168.199.131 | 3306 | Slave |
我们这里已经创建好了主从复制环境，这里我就不演示了
2.创建表和数据
我们是在Master实例上创建表和数据
root@localhost:mysql3306.sock [db1]> create table tb_2018 (
-> id int not null auto_increment,
-> cname varchar(32),
-> ctime datetime,
-> primary key(id)
-> );
root@localhost:mysql3306.sock [db1]> insert into tb_2018(cname,ctime) values ('unixfbi',now());
Query OK, 1 row affected (0.00 sec)
root@localhost:mysql3306.sock [db1]> insert into tb_2018(cname,ctime) values ('MySQL',now());
Query OK, 1 row affected (0.00 sec)
root@localhost:mysql3306.sock [db1]> insert into tb_2018(cname,ctime) values ('JAVA',now());
3.让主从数据不一致
我们在从库上添加一条数据，让主从数据不一致。
oot@localhost [db1]>insert into tb_2018(cname,ctime) values ('NET',now());
Query OK, 1 row affected (0.02 sec)
root@localhost [db1]>select * from tb_2018;
+----+---------+---------------------+
| id | cname | ctime |
+----+---------+---------------------+
| 1 | unixfbi | 2018-01-29 14:43:01 |
| 2 | MySQL | 2018-01-29 14:43:10 |
| 3 | JAVA | 2018-01-29 14:43:19 |
| 4 | NET | 2018-01-29 14:44:15 |
+----+---------+---------------------+
4 rows in set (0.00 sec)
4.验证主从数据是否一致
在Master实例上执行
# pt-table-checksum --nocheck-binlog-format --replicate=db1.checksum -h localhost -P3306 -u root -p unixfbi --ignore-databases=mysql --recursion-method="processlist"
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
01-29T14:45:30 0 0 44 1 0 0.496 db1.tb1
01-29T14:45:30 0 1 3 1 0 0.015 db1.tb_2018
01-29T14:45:30 0 0 1 1 0 0.264 db2.tb3
01-29T14:45:31 0 0 1 1 0 0.012 db2.tb4
01-29T14:45:31 0 0 6 1 0 0.013 sys.sys_config
01-29T14:45:31 0 0 2 1 0 0.013 wbx3306.t1
01-29T14:45:31 0 0 0 1 0 0.013 wbx3306.tp_1
发现db1.tb_2018这个表里的数据已经不一致了。
5.查看不一致信息
执行pt-table-sync命令之前一定要确保checksum表的存在，也就是说必须先验证数据是否一致，才能执行pt-table-sync命令。
这里我们只是查看并打印解决不一致问题的语句，所以我们这里使用pt-table-sync命令的--print参数。修复不一致的问题，我们需要使用--execute参数。
# pt-table-sync --replicate=db1.checksum h=192.168.199.230,u=root,p=unixfbi --print
DELETE FROM `db1`.`tb_2018` WHERE `id`='4' LIMIT 1 /*percona-toolkit src_db:db1 src_tbl:tb_2018 src_dsn:h=192.168.199.230,p=...,u=root dst_db:db1 dst_tbl:tb_2018 dst_dsn:h=dev-hd-node3,p=...,u=root lock:1 transaction:1 changing_src:db1.checksum replicate:db1.checksum bidirectional:0 pid:42455 user:ruowei host:db-node1*/;
直接打印出了解决主从数据不一致的语句。
6.修复主从数据不一致问题
这里我们需要使用pt-table-sync命令的--execute参数
# pt-table-sync --replicate=db1.checksum h=192.168.199.230,u=root,p=unixfbi --execute
执行修复命令后，我们再次检查看看数据是否一致。
# pt-table-checksum --nocheck-binlog-format --replicate=db1.checksum -h localhost -P3306 -u root -p unixfbi --ignore-databases=mysql --recursion-method="processlist"
Checking if all tables can be checksummed ...
Starting checksum ...
TS ERRORS DIFFS ROWS CHUNKS SKIPPED TIME TABLE
01-29T15:13:50 0 0 44 1 0 0.016 db1.tb1
01-29T15:13:50 0 0 3 1 0 0.015 db1.tb_2018
01-29T15:13:50 0 0 1 1 0 0.013 db2.tb3
01-29T15:13:50 0 0 1 1 0 0.012 db2.tb4
01-29T15:13:50 0 0 6 1 0 0.012 sys.sys_config
01-29T15:13:50 0 0 2 1 0 0.012 wbx3306.t1
01-29T15:13:50 0 0 0 1 0 0.013 wbx3306.tp_1
发现没有显示数据不一致的问题。
在从库上查看一下数据有什么变化：
root@localhost [db1]>select * from tb_2018;
+----+---------+---------------------+
| id | cname | ctime |
+----+---------+---------------------+
| 1 | unixfbi | 2018-01-29 14:43:01 |
| 2 | MySQL | 2018-01-29 14:43:10 |
| 3 | JAVA | 2018-01-29 14:43:19 |
+----+---------+---------------------+
3 rows in set (0.00 sec)
发现是把id=4的这条数据删除了，保证了和主库数据一致性的。
参考文档
http://blog.itpub.net/12679300/viewspace-1455303/
本文出自 “运维特工” 博客，转载请务必保留原文链接 和 http://www.unixfbi.com
UnixFBI 运维特工
www.unixfbi.com
