一、背景

    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，由引擎和日志格式决定