MySQL 5.7 GTID模式下 skip 1032 Error

一个偶然的事情，线上一部MySQL slave 被人误删了数据，然后又在 master上执行了同样的 delete 操作，导致从库报了1032错误。

其实这种情况下，如果能将缺少的记录重新insert 进去，再 start slave就可以完美解决；

问题在于不知道他具体操作了什么数据，所以想直接跳过这个事务。

脑海里回想了下GTID模式下跳过1032 的步骤，大概步骤是:

mysql> SET @@SESSION.GTID_NEXT= '4ab8feff-5272-11e8-9320-08002715584a:201840';
Query OK, 0 rows affected (0.04 sec)

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

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

mysql> SET GTID_NEXT='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)

就能解决问题。

问题的关键是如何定位SESSION.GTID_NEXT，由于时隔久远记不太清，于是顺手Google 了一把，没想到结果令人大跌眼镜。

竟然不止一个人说是直接看 Retrieved_Gtid_Set 接收的最后一个GTID 号：

我们回顾一下这两个指标的含义：

Retrieved_Gtid_Set: 表示 从库IO进程从主库已经接收到的事务的GTID集合。
Executed_Gtid_Set:表示 已经在从库上执行的事务的GTID集合。

已正常的思维思考一下，或许Executed_Gtid_Set更有参考意义？答案是NO。

这里我们需要关注的是从库报 1032 时， Relay_Master_Log_File 和 Exec_Master_Log_Pos 处在什么位置，这里才是从库真正卡住的位置

 

显而易见，这些事务都是来自于主库，所以我们应该去主库上的binlog 找到对应的事务的 GTID

mysqlbinlog --start-position=2102  -vv --base64-output=DECODE-ROWS  mybinlog.000010 >binlog-10.sql

看这里：

在2102 这个位置紧跟其后指定下一个事务的GTID：

SET @@SESSION.GTID_NEXT= '803ee8b1-af67-11e8-be2b-000c29ef4329:643'/*!*/;

 

那下一个事务是什么呢？

就是从 begin 到 commit 中间的语句，而二这个语句正是在主库删除记录的语句。

 

正是我们应该跳过的事务，所以正确的姿势是：

mysql> SET @@SESSION.GTID_NEXT= '803ee8b1-af67-11e8-be2b-000c29ef4329:643';

mysql> BEGIN;

mysql> COMMIT;

mysql> SET GTID_NEXT='AUTOMATIC';

 

到此为止，欢迎指正！

转载于:https://www.cnblogs.com/lidx/p/9723669.html