共计 4118 个字符，预计需要花费 11 分钟才能阅读完成。
本篇文章给大家分享的是有关 MySQL 主从不一致的修复过程是怎样的，丸趣 TV 小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着丸趣 TV 小编一起来看看吧。
昨天发现一个 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 的过程其实很复杂，大体有一下的步骤，当然我们可以简化一下，达到目标然后再深究。
在主库端开始做 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 就完全正常了。
以上就是 MySQL 主从不一致的修复过程是怎样的，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。
