故障分析 | Sql_slave_skip_counter 使用不规范对复制的影响

作者：唐龙哲

爱可生交付服务团队上海DBA，负责 MySQL 数据库故障处理及日常维护。擅长故障诊断

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

一、背景描述

最近在客户环境遇到一个 sql_slave_skip_counter 使用不规范引起的主从故障问题。

我们知道 mysql 的主从复制是逻辑复制，所以 slave 在应用 relay log 的过程中，经常会遇到错误，而参数 sql_slave_skip_counter 可以设置跳过多少个 event ，让从库 sql 继续回放。但是如果 sql_slave_skip_counter 使用不当，也会造成主从数据不一致。

以下为抓取的部分错误日志截图：

可以看到为了跳过报错的 SQL ，现场有手动设置过 SQL_SLAVE_SKIP_COUNTER=100000 ，表示跳过10万的 events ，而 binlog event 事件的多少，与事务表/非事务表、及 binlog 日志模式有关。

常见错误说明：

write_rows ：Duplicate entry（1062错误）主键冲突，主要表现为重复插入已经存在的记录;

update_rows ：Can’t find record（1032错误），无法发现需要更新的行记录。

sql_slave_skip_counter 参数说明：

从官方解释知道，sql_slave_skip_counter以event 为单位 skip ，直到 skip 完第N个 event 所在的 event group 才停止。对于事务表，一个 event group 对应一个事务; 对于非事务表，一个 event group 对应一条 SQL 语句。并且一个 event group 可以包含多个 event 事件。

详细解释，可以参考官方文档：

https://dev.mysql.com/doc/refman/5.6/en/set-global-sql-slave-skip-counter.html。

https://dev.mysql.com/doc/refman/8.0/en/replication-administration-skip.html。

二、测试 sql_slave_skip_counter 对复制的影响

使用显示开启事务方式(begin/commit)，模拟 delete/update 遇到 Can’t find record (1032) 错误，insert 中的 Duplicate entry(1062) 错误可以使用类似的方法去分析。此处使用 MySQL8.0.23 版本，基于 Row 日志模式 + Position 方式搭建异步复制架构。

2.1 准备数据

前提条件(主从库应用如下配置)：

-- 关闭GT