mysql sql_salve_skip_counter

案例分析：从库复制出错

1.    从错误日志和slave status来看，复制在relay_master_log_file=mysql-bin.000088这个日志文件的exec_master_log_pos=471880483这个position上出错了！

2.    因为show binlog events 这个命令不能针对relay_bin中继日志做读取event，所以我们还得回到主库上去读mysql-bin二进制日志文件。

3.    去主库执行show binlog events in 'mysql-bin.000088' from 471880483 limit 10;

可以看出从471880483 到471880982这个出问题的insert 语句，一共分成了三个event！（可以看出一个事务并非就是一个event，而会是三个event！begin/insert/commit）

4.    执行set global sql_salve_skip_counter=1!  此句表示从此刻的位置跳过1个event!

    另外在别的资料里还看到有两个策略：

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

    2、若N=1且当前event处于一个事务之内（BEGIN之后,COMMIT之前），则N不变，跳过当前event继续。

     说明：其实上面两个策略合起来就是一句话，当N=1时，会连续跳过若干个event，直到当前所在的事务结束。

    当然如果N>1，则跳过N个event！并且最后不能处于一个事务内！

5.    执行set global sql_salve_skip_counter=1! ，再去看错误日志

可以看出mysql从event=1 跳过了 第二个和第三个event，从第四个event新的pos=471880982 重新开始执行中继日志！