MySQL小误区:关于set global sql_slave_skip_counter=N 命令的一些点

本文详细介绍了在MySQL从库维护中如何使用setglobalsql_slave_skip_counter命令跳过多个事件,包括其工作原理、使用场景、与实际操作不符的问题以及解决策略。此外,还对比了不同引擎和日志格式下的行为差异。

 背景知识1

    在主从库维护中,有时候需要跳过某个无法执行的命令,需要在slave处于stop状态下,执行 set global sql_slave_skip_counter=N以跳过命令。常用的且不易用错的是N=1的情况,但N>1时,则不那么顾名思义,本文详细介绍N的意义,及使用注意事项。

 

    背景知识2

    MySQL从库从主库上复制binlog文件内容到本地执行。在binlog上命令以event的形式存在,并非一个命令对应一个event。以一个insert语句为例(引擎InnoDBbinglog_format=statement) binlog中实际上有三个event,分别为begin\insert\commit 命令类型都是Query_log_event.

 

    set global sql_slave_skip_counter=N的意思,即为在start slave时,从当前位置起,跳过Nevent。每跳过一个event,则N--.

 

    与实际情况不符?

    看到这里有同学就会问,这是有问题的。如果当前的执行位置是某个insert语句开头,那使用 N=1实际上是从begin\insert\commit的第二个开始执行,这个insert语句还是不能被跳过?

    实际上这里还有两个策略:

    1、若N=1且当前eventBEGIN N不变,跳过当前event继续。

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

 

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

    当然如果N>1,则每跳过一个event都要N--.

 

    命令举例:

    所以我们平时最常用的N=1的情况,都是下一个事务

    假设某个Pos之后执行如下命令( 引擎InnoDBbinglog_format=statement)

    insert into t values(x1);

    begin;

    insert into t values(x2);

    insert into t values(x3);

    commit;

   insert into t values(x4);

你的从库stopPos上,假设你要跳过前面几个命令直接执行插入x4的操作,则你的N设置为 4567均可。(X1语句为3event

 

   其他说明:

   上面举例中都特别说明了在innodb引擎和statement模式下。其他情况区别如下:

   1、若引擎为myisam(等不支持事务的引擎),且在statement下,则binlog中不会有begincommit,每个命令都是一个event

   2row模式的binlog里,一个insert语句实际上是两个eventTable_map_event Row_log_event), 计算时应与statement不同。

  3、在row模式下,不论引擎是否支持事务,一个insert语句都会加上BEGINcommit,也即变成4event

  4、基于InnoDB引擎表的insert/delete/update操作都有显式样的BEGIN /COMMIT.

 

  上面举的这个例子中,若为row模式,则要直接执行X4语句需要设置的N 510均可。

 

   小结:

   1set global sql_slave_skip_counter=N中的N是指跳过Nevent

   2、最好记的是N被设置为1时,效果跳过下一个事务

   3、跳过第Nevent后,位置若刚好落在一个事务内部,则会跳过这整个事务

   4、一个insert/update/delete不一定只对应一个event,由引擎和日志格式决定

  

    关联微薄 http://weibo.com/1933424965/xw2OlyWMi

   

<think>我们被要求回答:如何在MySQL中多次使用SETGLOBALSQL_SLAVE_SKIP_COUNTER跳过多个错误事件?根据引用内容,我们知道:-sql_slave_skip_counter用于在从库复制过程中跳过错误事件。-引用[1]和[4]都强调,建议每次只跳过1个事件(即设置N=1),即使需要跳过多个事件,也应该分开多次执行,每次跳过1个事件。-这样做的原因是:如果一次跳过多个事件(N>1),可能会跳过多个事件,而这些事件中可能包含一些重要的事件(比如事务的开始和提交),导致数据不一致或者后续复制错误。因此,正确的方法是:每次只跳过1个事件,重复执行直到跳过了所需的数量。具体步骤:1.停止从库复制:STOPSLAVE;2.设置跳过计数器为1:SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;3.启动从库复制:STARTSLAVE;4.检查复制状态:SHOWSLAVESTATUS\G-如果复制仍然因为另一个错误而停止,重复步骤1-3。-如果错误已经跳过,复制会继续,直到遇到下一个错误(如果有的话)。注意:每次跳过1个事件,然后观察复制状态,确保我们不会跳过不应该跳的事件。但是,如果我们需要跳过多个事件(比如N个事件),那么我们需要重复上述过程N次。例如,假设需要跳过3个事件:第一次:STOPSLAVE;SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;STARTSLAVE;然后检查状态,如果复制因为下一个错误又停止了,则再次执行:第二次:STOPSLAVE;SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;STARTSLAVE;第三次:STOPSLAVE;SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;STARTSLAVE;这样,我们就跳过了3个事件。为什么不一次性设置SQL_SLAVE_SKIP_COUNTER=3?引用[4]指出:当N>1时,它不仅仅跳过N个事件,而是跳过N个“事件组”。在基于语句的复制中,一个事件组通常对应一个SQL语句,但在基于行的复制中,一个事务可能包含多个事件(每个事件对应一行更改)。而且,一个事务可能包含多个事件组(比如事务的开始和提交分别是一个事件)。因此,如果设置N=3,可能会跳过多个事务,导致数据不一致。所以,强烈建议每次只跳过1个事件,即使需要跳过多个事件,也要分多次进行。另外,引用[1]也提到:假设跳过的值太多,可以分开多次,每次跳过最多一个事务(这里应该是事件),这样也能做到心中有数,并且是只有出错的时候才去跳。因此,总结如下:步骤:1.停止从库:STOPSLAVE;2.设置跳过计数器为1:SETGLOBALSQL_SLAVE_SKIP_COUNTER=1;3.启动从库:STARTSLAVE;4.检查复制状态(SHOWSLAVESTATUS\G),看是否还有错误。5.如果复制再次因错误停止,重复步骤1-4,直到跳过了所有需要跳过的事件。注意:在跳过事件后,务必检查主从数据的一致性,因为跳过事件可能会导致数据不一致。另外,如果错误事件非常多,建议先分析错误的原因,避免一直跳过事件。如果错误是重复出现的(比如主键冲突),可能需要从数据层面解决。根据引用[3]的例子,我们看到在跳过1个事件后,复制仍然停止,并且报错位置变化了(从之前的错误位置到了下一个错误位置),所以需要再次跳过。所以,多次跳过就是多次执行跳过1个事件的操作。最后,生成相关问题。</think>### 如何多次跳过 MySQL 复制错误事件 在 MySQL 主从复制中,当需要跳过多个错误事件时,**强烈建议每次仅跳过 1 个事件**,通过重复操作实现多个事件的跳过。这是最安全可控的方式,避免因跳过多个事件导致事务完整性破坏或数据不一致风险[^1][^4]。 #### 安全操作步骤: 1. **停止从库复制线程** ```sql STOP SLAVE; ``` 2. **单次跳过 1 个事件** ```sql SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; ``` 3. **重启复制并检查状态** ```sql START SLAVE; SHOW SLAVE STATUS\G ``` 4. **重复操作直到错误消除** - 若 `Last_Errno` 仍显示错误代码(如 1032) - 重复步骤 1-3,每次跳过 1 个事件 - 通过 `Exec_Master_Log_Pos` 字段观察位置变化[^3] #### 关键注意事项: 1. **禁止批量跳过** ❌ 切勿使用 `SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N`(N>1) - 可能跳过事务边界导致数据损坏 - 无法精确定位错误事件位置[^4] 2. **操作后必须验证** - 检查 `SHOW SLAVE STATUS` 输出: ```sql Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_Errno: 0 ``` - 使用 `pt-table-checksum` 校验主从数据一致性 3. **错误根源分析** 每次跳过事件后检查错误类型: - **重复 1032 错误**:表明主从存在持续数据差异 - **错误代码变化**:可能暴露更深层次的复制问题 > **最佳实践**:跳过操作后立即执行数据一致性校验,并查找根本原因。长期解决方案是启用 GTID 复制或使用 `pt-table-sync` 修复数据差异[^1][^4]。 --- ### 操作示例流程 ```mermaid graph TD A[复制报错停止] --> B[STOP SLAVE] B --> C[SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1] C --> D[START SLAVE] D --> E{检查 SHOW SLAVE STATUS} E -->|仍有错误| B E -->|无错误| F[数据一致性校验] F --> G[问题解决] ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值