mysql 主从修复_MySQL主从不一致的修复过程

昨天发现一个5.7的MySQL从库在应用日志的时候报出了错误。从库启用过了并行复制。Last Error的内容为:

Last_Error: Coordinator stopped because there were error(s) in the

worker(s). The most recent failure being: Worker 0 failed executing

transaction '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649' at master log

mysql-bin.000011, end_log_pos 5290535. See error log and/or

performance_schema.replication_applier_status_by_worker table for more

details about this failure or others, if any.

对于这类问题看起来还是比较陌生,如果想查看一些明细的信息,可以到binlog里面看到一些。此处的relay log是teststd-relay-bin.000013

/usr/local/mysql/bin/mysqlbinlog --no-defaults

--base64-output=DECODE-ROWS --verbose teststd-relay-bin.000013 >

/tmp/mysqlbin.log

而修复方式和常规的略有一些差别。

STOP SLAVE;

SET @@SESSION.GTID_NEXT = '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649';

BEGIN; COMMIT;

SET @@SESSION.GTID_NEXT = AUTOMATIC;

START SLAVE;

然后再次应用,不过我发现我这列碰到的问题貌似比想象的要麻烦一些。可以从错误日志看出是在更修改backend数据库的表sys_user_audit的时候抛出了错误。

2016-11-29T00:03:58.754386+08:00 161 [Note] Slave SQL thread for channel

'' initialized, starting replication in log 'mysql-bin.000011' at

position 5290028, relay log './teststd-relay-bin.000013' position: 27175

2016-11-29T00:03:58.754987+08:00 162 [ERROR] Slave SQL for channel '': Worker 0 failed executing transaction '8fc8d9ac-a62b-11e6-a3ee-a4badb1b4a00:7649' at master log mysql-bin.000011, end_log_pos 5290535; Could not execute Update_rows event on table backend.sys_user_audit; Can't find record in 'sys_user_audit', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log FIRST, end_log_pos 5290535, Error_code: 1032

手工跳过了几次之后,发现这样也不是事儿,如果这样的问题较多,可以直接修改参数slave_exec_mode来完成。

set global slave_exec_mode=IDEMPOTENT;

当然这种方式解决当前问题还是比较合适的,跟上了主库的变更,重新设置为原值。

set global slave_exec_mode=STRICT;很快从库的状态就正常了,但是又一个新的问题又来了。主从数据库的数据怎么不一致了。而且更加直接的是我对这个表在主从做了对比,发现数据是不一致的,从库的数据比主库少了9条。如此一来,这个从库就是不合格的。

怎么修复数据呢,一种直接的方式就是重建从库,但是这样不是一个很好的方案。还有其它的方案吗,使用navicator也是一个不错的方案,图形界面点点配配就可以完成。还有一种方案是使用pt工具来修复。

早就耳闻,今天终于感受了一下。

首先安装很常规,可以参考我之前的一篇文章。Percona-toolkit的安装和配置(r8笔记第86天)其实就是下载解压,基本的安装。

在主从库各创建一个临时作为同步的用户,先做checksum,然后根据checksum的情况来修复数据,这样就涉及两个命令行工具,pt-table-checksum和 pt-table-sync,当然这两个工具的选项很多,我只做一些基本的操作。

创建用户的方式如下,需要做对比主从checksum的数据库为backend

GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'pt_checksum'@'10.127.%.%' IDENTIFIED BY 'pt_checksum';

创建的临时数据库为percona,也需要赋予相应的权限。

grant all on percona.* to  'pt_checksum'@'10.127.%.%' ;

checksum的过程其实很复杂,大体有一下的步骤,当然我们可以简化一下,达到目标然后再深究。

eb4435f513b05409c5f5be5754e071c5.png

在主库端开始做checksum,如果碰到下面的错误。

# pt-table-checksum

h='10.127.128.99',u='pt_checksum',p='pt_checksum',P=3306 -d backend

--nocheck-replication-filters --replicate=percona.checksums

Replica teststd.test.com 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.

这个选项的具体含义后续再琢磨,在row模式下会有这种警告,可以忽略这项检查。

[root@testdb2 bin]# pt-table-checksum

h='10.127.128.99',u='pt_checksum',p='pt_checksum',P=3306 -d backend

--nocheck-replication-filters --replicate=percona.checksums

--no-check-binlog-format

TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE

11-29T17:45:34      0      0      105       1       0   0.017 backend.sys_resource

11-29T17:45:34      0      0       17       1       0   0.015 backend.sys_role

11-29T17:45:34      0      1       99       1       0   0.017 backend.sys_user

11-29T17:45:34      0      1      172       1       0   0.017 backend.sys_user_audit

完成之后,在percona下会就生成一个表,里面的数据就是一些对比的元数据,如果存在差别则会有diffs字段会有标示

如果确认无误,可以开始修复数据,借助pt-table-sync,先把SQL输出不执行,把主库和从库的信息都正确输入。

pt-table-sync --print --replicate=percona.checksums h=10.127.128.99,u=pt_checksum,p=pt_checksum,P=3306 h=10.127.130.58,u=pt_checksum,p=pt_checksum,P=3306

而这个操作的原理其实就是replace into。

REPLACE INTO `backend`.`sys_user`(`id`, `user_name`, xxxx) VALUES

('100', 'songlijiao@test-inc.com', 'songlijiao', xxxxx)

/*percona-toolkit src_db:backend src_tbl:sys_user

src_dsn:P=3306,h=10.127.128.99,p=...,u=pt_checksum dst_db:backend

dst_tbl:sys_user dst_dsn:P=3306,h=teststd.test.com,p=...,u=pt_checksum

lock:1 transaction:1 changing_src:percona.checksums

replicate:percona.checksums bidirectional:0 pid:28684 user:root

host:testdb2.test.com*/;

切记要注意权限,对于这个同步数据的用户要开通操作目标数据库的权限。

grant insert,delete,update,select on backend.* to 'pt_checksum'@'10.127.%.%' ;

这个过程持续的时间不长,很快就能够执行完毕,修复之后再次做checksum就完全正常了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在CentOS 7下配置MySQL 5.7.22的主从复制,需要以下步骤: 1.安装MySQL 5.7.22版本 在CentOS 7上安装MySQL 5.7.22,可以使用如下命令: ``` sudo yum install mysql-server ``` 2.配置主服务器 在主服务器的配置文件`/etc/my.cnf`中添加如下内容: ``` server-id=1 log-bin=mysql-bin binlog-do-db=test ``` 其中,`server-id`表示服务器的ID,`log-bin`表示开启二进制日志,`binlog-do-db`表示指定需要同步的数据库名称。 3.重新启动MySQL服务器 在修改了配置文件后,需要重新启动MySQL服务器: ``` sudo systemctl restart mysqld ``` 4.创建用于复制的用户 在主服务器上创建一个用于复制的用户,并授予复制权限: ``` GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'password'; FLUSH PRIVILEGES; ``` 其中,`slave_user`是用于复制的用户名,`password`是用户密码。 5.查看主服务器状态 在主服务器上运行如下命令查看主服务器状态: ``` SHOW MASTER STATUS; ``` 记录下`File`和`Position`的值,备用。 6.配置从服务器 在从服务器的配置文件`/etc/my.cnf`中添加如下内容: ``` server-id=2 replicate-do-db=test ``` 其中,`server-id`表示服务器的ID,`replicate-do-db`表示指定需要同步的数据库名称。 7.重新启动MySQL服务器 在修改了配置文件后,需要重新启动MySQL服务器: ``` sudo systemctl restart mysqld ``` 8.设置从服务器复制主服务器 在从服务器上运行如下命令,设置从服务器复制主服务器: ``` CHANGE MASTER TO MASTER_HOST='master_host_name', MASTER_USER='slave_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='master_log_file_name', MASTER_LOG_POS=master_log_pos; ``` 其中,`master_host_name`是主服务器的IP地址或主机名,`slave_user`和`password`是用于复制的用户名和密码,`master_log_file_name`和`master_log_pos`是之前在主服务器上记录的值。 9.启动从服务器复制 在从服务器上运行如下命令,启动从服务器复制: ``` START SLAVE; ``` 10.查看从服务器状态 在从服务器上运行如下命令查看从服务器状态: ``` SHOW SLAVE STATUS\G ``` 如果输出中`Slave_IO_Running`和`Slave_SQL_Running`的值都为`Yes`,则表示从服务器已经成功复制主服务器。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值