MySQL GTID复制Slave跳过错误事务Id以及复制排错问题总结

GTID复制典型的复制错误有两种：
1，数据对象级别的错误，包括主库上update的数据在从库上不存在，主从逐渐冲突，库表索引等对象的冲突等等，
　  如果是纯粹的跳过错误的话，这一类的错误需要跳过思路是找到主库binlog中对应的事务Id然后在从库上跳过即可。
2，日志找不到的错误，也即从库在执行利用主库上的binlog执行对应的事务的时候，因为主库上日志被删除，找不到对应的日志的错误
　  这一类的错误，根据主库的gtid_purged，更新从库的gtid_purged，也就是告诉从库，直接跳过主库中被删除的日志。

本文说的是第一种错误。

背景：安装完master之后，修改root密码的时候忘了关闭binlog，导致update mysql.user表的时候记录了binlog 

开启GTID的复制后，直接报错：
Could not execute Update_rows event on table mysql.user; Can't find record in 'user', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.000002, end_log_pos 744

网上有非常多的跳过GTID复制报错的文章，
当然GTID复制报错的原因有两种：
一种是数据不一致引起的（主库事物在从库上找不到对应数据，或者是数据主键冲突，索引冲突之类的）
另一种是主库上事物日志被清理，从库找不到主库的要重放的事物日志引起的（Got fatal error 1236 from master when reading data from binary log:）
显然这里是因为数据不一致引起的错误，最主要的是如何找到引起复制错误的事物号，然后跳过这个事物？
之前注意过这个细节问题，这次果然又遇到了。

如何找到造成复制错误对应的事物Id？

对于slave status中的信息，注意如下两行
Retrieved_Gtid_Set: 6d257f5b-5e6b-11e8-b668-5254003de1b6:1-547
Executed_Gtid_Set:
Retrieved_Gtid_Set是slave接收到的事务的信息，
Executed_Gtid_Set是slave已经执行的slave的信息，这里没有任何信息，意味着复制的时候从库遇到主库的第一个事物Id就发生了错误
也就是说第一个事务复制就不能执行，为什么第一个事务就无法正常复制，按道理，跳过 6d257f5b-5e6b-11e8-b668-5254003de1b6:1就可以的。

从复制报错来看，如下，说的是：Can't find record in 'user' ****

  Last_Errno: 1032
  Last_Error: Could not execute Update_rows event on table mysql.user; Can't find record in 'user', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;inlog.000002, end_log_pos 744
  Skip_Counter: 0
  Exec_Master_Log_Pos: 154

然后使用mysqlbinlog 解析主库上的binlog信息
如下是执行mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS binlog.000002 的结果

mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)

mysql> exit
Bye
[root@tencent01 mysql8000binlog]# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS binlog.000002
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#180523 17:26:57 server id 8000  end_log_pos 123 CRC32 0x7a72d0c2       Start: binlog v 4, server v 5.7.20-log created 180523 17:26:57 at startup
ROLLBACK/*!*/;
# at 123
#180523 17:26:57 server id 8000  end_log_pos 154 CRC32 0x1e585b38       Previous-GTIDs
# [empty]
# at 154
#180523 17:27:08 server id 8000  end_log_pos 219 CRC32 0xcf9ed3c3       GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'/*!*/;
# at 219
#180523 17:27:08 server id 8000  end_log_pos 287 CRC32 0x5ca28a69       Query   thread_id=5     exec_time=0     error_code=0
SET TIMESTAMP=1527067628/*!*/;
SET @@session.pseudo_thread_id=5/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=45/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 287
#180523 17:27:08 server id 8000  end_log_pos 459 CRC32 0xf4845b1b       Table_map: `mysql`.`user` mapped to number 4
# at 459
#180523 17:27:08 server id 8000  end_log_pos 744 CRC32 0x74306d73       Update_rows: table id 4 flags: STMT_END_F
### UPDATE `mysql`.`user`
### WHERE
###   @1='localhost' /* STRING(180) meta=65204 nullable=0 is_null=0 */
###   @2='root' /* STRING(96) meta=65120 nullable=0 is_null=0 */
###   @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @4=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @5=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @6=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @7=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @10=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @11=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @12=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @13=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @14=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @15=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @16=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @17=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @18=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @19=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @20=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @21=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @22=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @23=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @24=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @25=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @26=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @27=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @28=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @29=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @30=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @31=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @32=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @33='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @34='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @35='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @36=0 /* INT meta=0 nullable=0 is_null=0 */
###   @37=0 /* INT meta=0 nullable=0 is_null=0 */
###   @38=0 /* INT meta=0 nullable=0 is_null=0 */
###   @39=0 /* INT meta=0 nullable=0 is_null=0 */
###   @40='mysql_native_password' /* STRING(192) meta=65216 nullable=0 is_null=0 */
###   @41='' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
###   @42=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @43=1527067612 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
###   @44=NULL /* SHORTINT meta=0 nullable=1 is_null=1 */
###   @45=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
### SET
###   @1='%' /* STRING(180) meta=65204 nullable=0 is_null=0 */
###   @2='root' /* STRING(96) meta=65120 nullable=0 is_null=0 */
###   @3=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @4=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @5=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @6=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @7=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @8=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @9=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @10=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @11=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @12=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @13=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @14=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @15=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @16=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @17=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @18=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @19=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @20=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @21=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @22=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @23=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @24=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @25=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @26=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @27=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @28=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @29=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @30=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @31=2 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @32=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @33='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @34='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @35='' /* BLOB/TEXT meta=2 nullable=0 is_null=0 */
###   @36=0 /* INT meta=0 nullable=0 is_null=0 */
###   @37=0 /* INT meta=0 nullable=0 is_null=0 */
###   @38=0 /* INT meta=0 nullable=0 is_null=0 */
###   @39=0 /* INT meta=0 nullable=0 is_null=0 */
###   @40='mysql_native_password' /* STRING(192) meta=65216 nullable=0 is_null=0 */
###   @41='*81F5E21E35407D884A6CD4A731AEBFB6AF209E1B' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */
###   @42=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
###   @43=1527067612 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
###   @44=NULL /* SHORTINT meta=0 nullable=1 is_null=1 */
###   @45=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */
# at 744
#180523 17:27:08 server id 8000  end_log_pos 813 CRC32 0xd3a07e78       Query   thread_id=5     exec_time=0     error_code=0
SET TIMESTAMP=1527067628/*!*/;
COMMIT
/*!*/;
# at 813
#180523 17:27:08 server id 8000  end_log_pos 878 CRC32 0x6451705b       GTID    last_committed=1        sequence_number=2       rbr_only=no
SET @@SESSION.GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:2'/*!*/;
# at 878
#180523 17:27:08 server id 8000  end_log_pos 965 CRC32 0x7451238c       Query   thread_id=6     exec_time=0     error_code=0
SET TIMESTAMP=1527067628/*!*/;
/*!C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=45/*!*/;
SET @@session.time_zone='SYSTEM'/*!*/;
flush privileges
/*!*/;
# at 965
#180523 17:27:08 server id 8000  end_log_pos 988 CRC32 0x108e7f09       Stop
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@tencent01 mysql8000binlog]#

不难理解，在master安装之后，第一时间修改了root的密码，那么修改root密码应该是第一个事务，
因此到了slave上，第一个事务就是无法执行的，为什么系统表（mysql.user）不允许复制事务？这一点先抛开，
如何在binlog中确认是哪一个事务Id？
上面说的是 Exec_Master_Log_Pos: 154，end_log_pos 744，也就是在这个偏移量之间的事务是导致slave无法复制的，这个事务Id正式1，也即GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
这里涉及利用Exec_Master_Log_Pos和end_log_pos 找事物Id的问题，从名字大概能猜到是这两个偏移量之间的一个事物Id
这两个偏移量之间的事物Id，也就是 '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
笔者一开始是找end_log_pos 744后面的事物Id，也即事物2，然后在从库设置跳过，怎么也不行。

对于数据冲突之列的复制错误，至于跳过事物Id本身，就不复杂了。

(1)停止slave进程
mysql> STOP SLAVE;
(2)设置事务号，事务号从Retrieved_Gtid_Set获取
在session里设置gtid_next，即跳过这个GTID
mysql> SET GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
(3)设置空事物
mysql> BEGIN; COMMIT;
(4)恢复事物号
mysql> SET SESSION GTID_NEXT = AUTOMATIC;
(5)启动slave进程
mysql> START SLAVE;
跳过一个事务之后，重启slave，恢复正常

 稍等几秒钟，从库很快就追上主库了

学而不思则罔，思而不学则殆。更多的时候是需要大胆去尝试，去折腾，在慢慢回味其中的道理，掌握了理论，动手试一遍，就大概清楚了。

 对于跳过MySQL主从复制的一些总结：

经常遇到不同的复制错误，通过show slave status的结果，通常是看是slave_io_running和slave_sql_running来判断slave复制是否正常。
之前总是纠结slave_io_running为NO的时候，怎么怎么办，slave_sql_running为NO的时候怎么怎么办，
然后上网查出来各种攻略或者解决办法，答案可谓是五花八门，运气好一下子就解决了，运气不好，怎么也解决不了,类似的问题还会出现。

如果结合原理，不管是哪种复制方式，其实根本不用上网上查各种五花八门的解决办法，自己认真分析一下，原因大概就猜个差不多了。

1，对于slave_io_running为NO的情况：
首先要想，slave_io_running线程是干嘛的？连接至master 往slave机器上拉master机器上的binlog的啊，那么，如果当slave_io_running为NO的时候，原因是什么？
肯定是slave连不上master了，slave连不上master原因又是什么呢？
无外乎用户复制的账号权限不足、slave与master之间的网络不通、change master的时候密码写错了、端口号写错了等等原因都有可能，
需要自己有目标地去排查，而不是上来就上网搜，一种一种办法尝试，别人的问题可能有别人的原因，尝试用别人的办法解决自己的问题，不一定总是凑效的。

2，对于slave_sql_running为NO的情况：
首先要想，slave_sql_running线程是干嘛的？是解析slave_io_running下载过来的master上的binlog的，
如果slave_io_running为YSE，slave_sql_running为NO，也就是说binlog传输过来了，解析过程出错了
哪又是什么原因？也无外乎是master上的日志无法应用到slave上，
此时分为两种情况，举个例子，如下截图，last_error 中也写的很清楚了，err_key_not_found
那就是说说在应用master上一个事物的binlog的时候，slave找不到对应的数据，至于解决办法先不说，最主要的是找到真正的原因。,

3，最后猜测一种情况：
初始化复制的时候，会不会出现slave_io_running为NO，slave_sql_running为YSE的情况？
我想是不会的，slave_io_running是下载（传输）master的binlog的，slave_sql_running是解析下载过来binlog的，怎么可能会出现master的binlog都没有下载过来，slave能够正常解析binlog呢？

上述错误是主从复制的第一种错误，意思说应用某一条事物的时候出现了错误
另一种是主库上binlog日志被清理（比如过期自动情况等等），
从库在执行主库的事物Id的时候找不到master上的binlog（对应的错误信息是Got fatal error 1236 from master when reading data from binary log:）
两种错误，是两种不同的解决办法，虽然说都是跳过错误日志，但是跳跟跳还是不太一样的
gtid跳过复制错误的方法：

对于第一种错误，说明从库在应用当前事物Id的时候出错了，从库上无法应用某一个事物编号，数据要跳过一个错误，正常操作如下：

stop slave;
set gtid_next='6d257f5b-5e6b-11e8-b668-5254003de1b6:n';
begin;
commit;
set gtid_next='AUTOMATIC';
start slave;

对于master上的binlog被清理，slave上找不到对应的binlog，需要跳过主库上所有被清理的binlog，
在主库执行show variables like '%gtid_purged%'，看主库清理的日志的范围，比如：6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578
那么就要跳过主库上被清理的binlog的范围，需要设置从库上的gtid_purged的范围即可

stop slave;
reset master;
set global gtid_purged='6d257f5b-5e6b-11e8-b668-5254003de1b6:1-699578';
start slave;

有上述两种处理方式来看，不同的错误需要不同的处理方式，如果弄清楚了背后的原理，其实，问题并不难解决。

所有的问题，都需要具体分析其原因，然后找到其解决方案，这其中，都依赖于事物背后的原理，因此说，学习某种技术，要首选弄清楚其背后的原理，才是根本。