公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-11-29 23:57:51 · 原文链接

昨天发现一个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的过程其实很复杂，大体有一下的步骤，当然我们可以简化一下，达到目标然后再深究。