先给出一个场景:
主库与从库状态一致,我将从库的hello库删除,此时我在主库上删除hello,这是就会报错,主从同时中断。
其实仔细想想还是很合乎逻辑的,从库是依靠在主库处拉去的binlog的做恢复,主库drop database hello ,从库同样会执行该语句,那从库发现它根本就没有这个库,此时从库认为与主库已经不一致了,主从中断。
那该怎么办?从库跳过这条不执行呗。
问题来了, set global sql_slave_skip_counter=N,这条语句的N到底指什么呢?
MySQL从库从主库上复制binlog文件内容到本地执行。在binlog上命令以event的形式存在,并非一个命令对应一个event。以一个insert语句为例(引擎InnoDB、binglog_format=statement), 在binlog中实际上有三个event,分别为begin\insert\commit 。 命令类型都是Query_log_event.
而set global sql_slave_skip_counter=N的意思,即为在start slave时,从当前位置起,跳过N个event。
说明:当N=1时,会连续跳过若干个event,直到当前所在的事务结束。
命令举例:
我们平时最常用的N=1的情况,都是下一个事务。
假设某个Pos之后执行如下命令( 引擎InnoDB、binglog_format=statement),
insert into t values(x1);
begin;
insert into t values(x2);
insert into t values(x3);
commit;
insert into t values(x4);
你的从库stop在Pos上,假设你要跳过前面几个命令直接执行插入x4的操作,则你的N设置为 4或5或6或7均可。(X1语句为3个event)
其他说明:
上面举例中都特别说明了在innodb引擎和statement模式下。其他情况区别如下:
1、若引擎为myisam(等不支持事务的引擎),且在statement下,则binlog中不会有begin和commit,每个命令都是一个event;
2、row模式的binlog里,一个insert语句实际上是两个event(Table_map_event和 Row_log_event), 计算时应与statement不同。
3、在row模式下,不论引擎是否支持事务,一个insert语句都会加上BEGIN和commit,也即变成4个event。
4、基于InnoDB引擎表的insert/delete/update操作都有显式样的BEGIN /COMMIT.
上面举的这个例子中,若为row模式,则要直接执行X4语句需要设置的N为 5~10均可。
小结:
1、set global sql_slave_skip_counter=N中的N是指跳过N个event
2、最好记的是N被设置为1时,效果跳过下一个事务。
3、跳过第N个event后,位置若刚好落在一个事务内部,则会跳过这整个事务
4、一个insert/update/delete不一定只对应一个event,由引擎和日志格式决定