这篇文章主要介绍“分析MySQL的slave_skip_errors参数对MGR可用性的影响”，在日常操作中，相信很多人在分析MySQL的slave_skip_errors参数对MGR可用性的影响问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”分析MySQL的slave_skip_errors参数对MGR可用性的影响”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

一、案例描述

MGR在遇到表不存在的情况下，节点没有退出节点而是爆出一个警告，并且节点状态也正常，警告如下：

2019-10-17T21:16:11.564211+08:0010[Warning]SlaveSQLforchannelgroup_replication_applier':Worker1failedexecutingtransaction'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:8'atmasterlog,end_log_pos220;Errorexecutingrowevent:'Table'test.a_1'doesn'texist',Error_code:1146

集群状态如下：

[root@mysql.sock][test]>select*fromperformance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+|CHANNEL_NAME|MEMBER_ID|MEMBER_HOST|MEMBER_PORT|MEMBER_STATE|+---------------------------+--------------------------------------+-------------+-------------+--------------+|group_replication_applier|9fd479bb-f0d8-11e9-9381-000c29105312|mysql_1|3306|ONLINE||group_replication_applier|a8833a96-f0d8-11e9-a9f4-000c291fd9a5|mysql_2|3306|ONLINE||group_replication_applier|b2968fe2-f0d8-11e9-a8ff-000c29c89e42|mysql_3|3306|ONLINE|+---------------------------+--------------------------------------+-------------+-------------+--------------+3rowsinset(0.00sec)

当时觉得很奇怪，我们知道这种错误即便是在主从情况下也是报错的SQL线程退出的，MGR居然还能在线，这种情况数据已经不同步了，应该报错并且剔除节点才对。

二、问题分析

随即一些感兴趣的同学马上进行了测试，测试结果和上面不一致，测试结果是报错而不是出警告如下：

2019-10-17T09:16:34.317542Z84[ERROR]SlaveSQLforchannel'group_replication_applier':Errorexecutingrowevent:'Table'test.emp1'doesn'texist',Error_code:1146

并且这种情况表不存在的节点已经被剔除掉了。下面是正常情况的节点状态：

secondary1节点：[root@mysql.sock][test]>select*fromperformance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+|CHANNEL_NAME|MEMBER_ID|MEMBER_HOST|MEMBER_PORT|MEMBER_STATE|+---------------------------+--------------------------------------+-------------+-------------+--------------+|group_replication_applier|a8833a96-f0d8-11e9-a9f4-000c291fd9a5|mysql_2|3306|ERROR|+---------------------------+--------------------------------------+-------------+-------------+--------------+1rowinset(0.00sec)secondary2节点：[root@mysql.sock][test]>select*fromperformance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+|CHANNEL_NAME|MEMBER_ID|MEMBER_HOST|MEMBER_PORT|MEMBER_STATE|+---------------------------+--------------------------------------+-------------+-------------+--------------+|group_replication_applier|b2968fe2-f0d8-11e9-a8ff-000c29c89e42|mysql_3|3306|ERROR|+---------------------------+--------------------------------------+-------------+-------------+--------------+1rowinset(0.00sec)

那么疑问就是为什么同样是MGR一个是警告一个是错误呢，并且前者还能处于正常同步状态。不错看到题目就知道这里和slave_skip_errors参数有关。

三、测试模拟

我们知道再Master-Slave中如果遇到从库表不存在肯定是报错的，除非设置slave_skip_errors参数，当然我在线上重来没有设置过这个参数，并且通过这个案例我们发现本参数对MGR也有影响，如下测试方法：

我们在3个节点都开启slave-skip-errors= ddl_exist_errors

如下图：

然后搭建3节点single-primary模式的MGR集群。

集群搭建正常。

然后执行如下操作：

[root@mysql.sock][(none)]>setsql_log_bin=0;QueryOK,0rowsaffected(0.00sec)[root@mysql.sock][(none)]>createtabletest.a_1(idbigintauto_incrementprimarykey,namevarchar(20));QueryOK,0rowsaffected(0.01sec)[root@mysql.sock][(none)]>setsql_log_bin=1;QueryOK,0rowsaffected(0.00sec)

此时primary节点是有a_1表的，但是因为binlog关闭的原因，两个secondary节点是不存在a_1表的。

然后我们插入数据：

[root@mysql.sock][test]>insertintotest.a_1values(null,'tom');QueryOK,1rowaffected(0.02sec)

此时，primary节点因为存在a_1表，所以能够插入，但是两个secondary节点不存在a_1表，所以插入是失败的。数据产生不一致。正常情况下这种数据不一致会导致2个secondary节点被提出集群才对。但是实际上3个节点都是正常的，集群并没有失效。

[root@mysql.sock][test]>select*fromtest.a_1;+----+------+|id|name|+----+------+|1|tom|+----+------+1rowinset(0.00sec)[root@mysql.sock][test]>select*fromperformance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+|CHANNEL_NAME|MEMBER_ID|MEMBER_HOST|MEMBER_PORT|MEMBER_STATE|+---------------------------+--------------------------------------+-------------+-------------+--------------+|group_replication_applier|9fd479bb-f0d8-11e9-9381-000c29105312|mysql_1|3306|ONLINE||group_replication_applier|a8833a96-f0d8-11e9-a9f4-000c291fd9a5|mysql_2|3306|ONLINE||group_replication_applier|b2968fe2-f0d8-11e9-a8ff-000c29c89e42|mysql_3|3306|ONLINE|+---------------------------+--------------------------------------+-------------+-------------+--------------+3rowsinset(0.00sec)

此时去2个secondary节点读取test.a_1表，表是不存在的。

secondary1：[root@mysql.sock][test]>select*fromtest.a_1;ERROR1146(42S02):Table'test.a_1'doesn'texist[root@mysql.sock][test]>secondary2：[root@mysql.sock][test]>select*fromtest.a_1;ERROR1146(42S02):Table'test.a_1'doesn'texist

error log输出信息：（set global log_error_verbosity = 3;)

2019-10-17T21:16:11.564211+08:0010[Warning]SlaveSQLforchannel'group_replication_applier':Worker1failedexecutingtransaction'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:8'atmasterlog,end_log_pos220;Errorexecutingrowevent:'Table'test.a_1'doesn'texist',Error_code:1146四、slave_skip_errors源码生效点

这个设置在Rows_log_event::do_apply_event 函数中生效，也就是DML Event开始应用的时候生效，这是常规的SQL线程（或者Worker线程）调用的。

#ifdefHAVE_REPLICATIONif(opt_slave_skip_errors)add_slave_skip_errors(opt_slave_skip_errors);#endifif(open_and_lock_tables(thd,rli->tables_to_lock,0))//打开表{uintactual_error=thd->get_stmt_da()->mysql_errno();if(thd->is_slave_error||thd->is_fatal_error){if(ignored_error_code(actual_error))//这里受到slave_skip_errors参数控制ignored_error_code会将slave_skip_errors的参数设置读取出来{if(log_warnings>1)rli->report(WARNING_LEVEL,actual_error,"Errorexecutingrowevent:'%s'",(actual_error?thd->get_stmt_da()->message_text():"unexpectedsuccessorfatalerror"));thd->get_stmt_da()->reset_condition_info(thd);clear_all_errors(thd,const_cast<Relay_log_info*>(rli));error=0;gotoend;}else{rli->report(ERROR_LEVEL,actual_error,"Errorexecutingrowevent:'%s'",(actual_error?thd->get_stmt_da()->message_text():"unexpectedsuccessorfatalerror"));thd->is_slave_error=1;const_cast<Relay_log_info*>(rli)->slave_close_thread_tables(thd);DBUG_RETURN(actual_error);}}

可以看到MGR的执行逻辑受到了该参数的影响。

到此，关于“分析MySQL的slave_skip_errors参数对MGR可用性的影响”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！