剖析MySQL的slave_skip_errors参数对MGR可用性的影响
发布时间：2021-12-23 11:47:07 所属栏目：MySql教程 来源：互联网
导读：这篇文章主要介绍分析MySQL的slave_skip_errors参数对MGR可用性的影响，在日常操作中，相信很多人在分析MySQL的slave_skip_errors参数对MGR可用性的影响问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答分析MySQL的slave_ski
|
这篇文章主要介绍“分析MySQL的slave_skip_errors参数对MGR可用性的影响”，在日常操作中，相信很多人在分析MySQL的slave_skip_errors参数对MGR可用性的影响问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”分析MySQL的slave_skip_errors参数对MGR可用性的影响”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！ 一、案例描述 MGR在遇到表不存在的情况下，节点没有退出节点而是爆出一个警告，并且节点状态也正常，警告如下： 2019-10-17T21:16:11.564211+08:00 10 [Warning] Slave SQL for channel group_replication_applier': Worker 1 failed executing transaction 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:8' at master log , end_log_pos 220; Error executing row event: 'Table 'test.a_1' doesn't exist', Error_code: 1146 集群状态如下： [root@mysql.sock][test]>select * from performance_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 | +---------------------------+--------------------------------------+-------------+-------------+--------------+ 3 rows in set (0.00 sec) 当时觉得很奇怪，我们知道这种错误即便是在主从情况下也是报错的SQL线程退出的，MGR居然还能在线，这种情况数据已经不同步了，应该报错并且剔除节点才对。 二、问题分析 随即一些感兴趣的同学马上进行了测试，测试结果和上面不一致，测试结果是报错而不是出警告如下： 2019-10-17T09:16:34.317542Z 84 [ERROR] Slave SQL for channel 'group_replication_applier': Error executing row event: 'Table 'test.emp1' doesn't exist', Error_code: 1146 并且这种情况表不存在的节点已经被剔除掉了。下面是正常情况的节点状态： secondary 1节点： [root@mysql.sock][test]>select * from performance_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 | +---------------------------+--------------------------------------+-------------+-------------+--------------+ 1 row in set (0.00 sec) secondary 2节点： [root@mysql.sock][test]>select * from performance_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 | +---------------------------+--------------------------------------+-------------+-------------+--------------+ 1 row in set (0.00 sec) 那么疑问就是为什么同样是MGR一个是警告一个是错误呢，并且前者还能处于正常同步状态。不错看到题目就知道这里和slave_skip_errors参数有关。 三、测试模拟 我们知道再Master-Slave中如果遇到从库表不存在肯定是报错的，除非设置slave_skip_errors参数，当然我在线上重来没有设置过这个参数，并且通过这个案例我们发现本参数对MGR也有影响，如下测试方法： 我们在3个节点都开启slave-skip-errors= ddl_exist_errors 如下图： 分析MySQL的slave_skip_errors参数对MGR可用性的影响 然后搭建3节点single-primary模式的MGR集群。 分析MySQL的slave_skip_errors参数对MGR可用性的影响 集群搭建正常。 然后执行如下操作： [root@mysql.sock][(none)]>set sql_log_bin=0; Query OK, 0 rows affected (0.00 sec) [root@mysql.sock][(none)]>create table test.a_1(id bigint auto_increment primary key,name varchar(20)); Query OK, 0 rows affected (0.01 sec) [root@mysql.sock][(none)]>set sql_log_bin=1; Query OK, 0 rows affected (0.00 sec) 此时primary节点是有a_1表的，但是因为binlog关闭的原因，两个secondary节点是不存在a_1表的。 然后我们插入数据： [root@mysql.sock][test]>insert into test.a_1 values(null,'tom'); Query OK, 1 row affected (0.02 sec) 此时，primary节点因为存在a_1表，所以能够插入，但是两个secondary节点不存在a_1表，所以插入是失败的。数据产生不一致。正常情况下这种数据不一致会导致2个secondary节点被提出集群才对。但是实际上3个节点都是正常的，集群并没有失效。 [root@mysql.sock][test]>select * from test.a_1; +----+------+ | id | name | +----+------+ | 1 | tom | +----+------+ 1 row in set (0.00 sec) [root@mysql.sock][test]>select * from performance_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 | +---------------------------+--------------------------------------+-------------+-------------+--------------+ 3 rows in set (0.00 sec) 此时去2个secondary节点读取test.a_1表，表是不存在的。 secondary 1： [root@mysql.sock][test]>select * from test.a_1; ERROR 1146 (42S02): Table 'test.a_1' doesn't exist [root@mysql.sock][test]> secondary 2： [root@mysql.sock][test]>select * from test.a_1; ERROR 1146 (42S02): Table 'test.a_1' doesn't exist error log输出信息：（set global log_error_verbosity = 3;) 2019-10-17T21:16:11.564211+08:00 10 [Warning] Slave SQL for channel 'group_replication_applier': Worker 1 failed executing transaction 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:8' at master log , end_log_pos 220; Error executing row event: 'Table 'test.a_1' doesn't exist', Error_code: 1146 四、slave_skip_errors源码生效点 这个设置在Rows_log_event::do_apply_event 函数中生效，也就是DML Event开始应用的时候生效，这是常规的SQL线程（或者Worker线程）调用的。 #ifdef HAVE_REPLICATION if (opt_slave_skip_errors) add_slave_skip_errors(opt_slave_skip_errors); #endif if (open_and_lock_tables(thd, rli->tables_to_lock, 0))//打开表 { uint actual_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, "Error executing row event: '%s'", (actual_error ? thd->get_stmt_da()->message_text() : "unexpected success or fatal error")); thd->get_stmt_da()->reset_condition_info(thd); clear_all_errors(thd, const_cast<Relay_log_info*>(rli)); error= 0; goto end; } else { rli->report(ERROR_LEVEL, actual_error, "Error executing row event: '%s'", (actual_error ? thd->get_stmt_da()->message_text() : "unexpected success or fatal error")); 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可用性的影响”的学习就结束了，希望能够解决大家的疑惑。  （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
