MySQL:主从一个较为奇怪的报警

2022-01-10  本文已影响0人  重庆八怪

今天遇到一个问题简单记录如下,因为第一次遇到。

一、问题展示

主从报警如下:


2022-01-10T11:42:26.761755Z 3 [Warning] Slave SQL for channel '': Worker 1 failed executing transaction '00320cc8-39f9-11ec-b5ba-000c2929706d:1' at master log binlog.000001, 
end_log_pos 426; Could not execute Delete_rows event on table teset110.test; Can't find record in 'test', Error_code: 1032; handler error HA_ERR_END_OF_FILE; 
the event's master log FIRST, end_log_pos 426, Error_code: 1032

当然这里是我模拟的,一般遇到这个这个问题,主从肯定是要报错的,但是这里没有报错只是做了一个警告,主从状态依旧正常。

二、和slave_skip_errors参数相关?

第一反应当然是常见的slave_skip_errors参数,但是看了一下slave_skip_errors参数,并没有设置。
并且我测试了一下如果是slave_skip_errors跳过了错误,日志是note级别的,而不是wanring级别如下:

2022-01-10T11:23:47.088602Z 3 [Note] Slave SQL for channel '': Worker 1 failed executing transaction '00320cc8-39f9-11ec-b5ba-000c2929706d:6' at master log binlog.000002, 
end_log_pos 1700; Could not execute Delete_rows event on table teset110.test; Can't find record in 'test', Error_code: 1032; handler error HA_ERR_END_OF_FILE; 
the event's master log binlog.000002, end_log_pos 1700, Error_code: 1032

三、简单查看代码

既然一时间找不到原因,那么就根据错误搜索一下代码,然后简单跟一下。发现如下:


image.png

那么这里就是和我们的参数slave_exec_mode有关了,当slave_exec_mode设置为IDEMPOTENT的时候,原有的报错级别会变为warning,当然如果是slave_skip_errors则报错级别为note。

稍微翻了一下手册如下:
IDEMPOTENT mode is intended for use in multi-source replication, circular replication, and some other special replication scenarios for NDB Cluster Replication.

不建议在正常的主从中设置slave_exec_mode和slave_skip_errors等参数,避免主从不一致的情况。

上一篇 下一篇

猜你喜欢

热点阅读