MySQL SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N 的解释

一、背景
2016-08-01发现3650专家网双主中断，问题原因是因为主键冲突，这时候使用 SET GLOBAL SQL_SLAVE_SKIP_COUNTER 解决问题的时候，产生了一些疑问，下面是问题总结。
二、SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N说明
官方解释：This statement skips the next N events from the master.(即是跳过N个events，这里最重要的是理解event的含义。在mysql中,对于sql的 binary log 实际上是由一连串的event组成的一个组,即事务组。)
MySQL从库从主库上复制binlog文件内容到本地执行。在binlog上命令以event的形式存在，并非一个命令对应一个event。以一个insert语句为例
1、引擎InnoDB、binglog_format=statement， 在binlog中实际上有三个event，分别为begin\insert\commit 。 命令类型都是Query_log_event。





2、row模式的binlog里，event（Table_map_event和 Row_log_event) 计算时应与statement不同，不论引擎是否支持事务，一个insert语句都会加上BEGIN和commit，也即变成4个event。





3、基于InnoDB引擎表的insert/delete/update操作都有显式样的BEGIN /COMMIT。
看到这里有同学就会问，这是有问题的。如果当前的执行位置是某个insert语句开头，那使用 N=1实际上是从begin\insert\commit的第二个开始执行，这个insert语句还是不能被跳过。

1、若N=1且当前event为BEGIN， 则N不变，跳过当前event继续。

2、若N=1且当前event处于一个事务之内（BEGIN之后,COMMIT之前），则N不变，跳过当前event继续。
当然如果N>1，则每跳过一个event都要N--，上面两个策略合起来就是一句话，当N=1时，会连续跳过若干个event，直到当前所在的事务结束。

三、测试（模拟专家网线上主键冲突）
1、表DDL



2、首先手动从库插入3条测试数据





3、主库再插入3条一样的数据造成人为的主键冲突错误





4、这时候我们在从库show slave status\G会发现



5、这时候我们想修复主从复制如果用SET GLOBAL SQL_SLAVE_SKIP_COUNTER这个方法应该跳过多少个event呢?我们可以使用以下方法：
1）首先主库 show binlog events in 'mysql-bin.000011' from 810; （file和pos根据错误信息填写）



2）从库根据event行数跳过响应event



3）查看从库状态是否被修复



四、结论
1、set global sql_slave_skip_counter=N中的N是指跳过N个event
2、最好记的是N被设置为1时，效果跳过下一个事务。
3、跳过第N个event后，位置若刚好落在一个事务内部，则会跳过这整个事务
4、一个insert/update/delete不一定只对应一个event，由引擎和日志格式决定