分析MySQL的slave

121次阅读

共计 6507 个字符，预计需要花费 17 分钟才能阅读完成。

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

一、案例描述

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

集群状态如下：

[[email protected]][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 节点：[[email protected]][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 节点：[[email protected]][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

如下图：

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

集群搭建正常。

然后执行如下操作：

[[email protected]][(none)] set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)
[[email protected]][(none)] create table test.a_1(id bigint auto_increment primary key,name varchar(20));
Query OK, 0 rows affected (0.01 sec)
[[email protected]][(none)] set sql_log_bin=1;
Query OK, 0 rows affected (0.00 sec)

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

然后我们插入数据：

[[email protected]][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 个节点都是正常的，集群并没有失效。

[[email protected]][test] select * from test.a_1;
+----+------+
| id | name |
+----+------+
| 1 | tom |
+----+------+
1 row in set (0.00 sec)
[[email protected]][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：[[email protected]][test] select * from test.a_1;
ERROR 1146 (42S02): Table  test.a_1  doesn t exist
[[email protected]][test] 
secondary 2：[[email protected]][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 可用性的影响”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！

正文完