分析MySQL的slave

167次閱讀

共計(jì) 6507 個(gè)字符，預(yù)計(jì)需要花費(fèi) 17 分鐘才能閱讀完成。

這篇文章主要介紹“分析 MySQL 的 slave_skip_errors 參數(shù)對(duì) MGR 可用性的影響”，在日常操作中，相信很多人在分析 MySQL 的 slave_skip_errors 參數(shù)對(duì) MGR 可用性的影響問(wèn)題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”分析 MySQL 的 slave_skip_errors 參數(shù)對(duì) MGR 可用性的影響”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著丸趣 TV 小編一起來(lái)學(xué)習(xí)吧！

一、案例描述

MGR 在遇到表不存在的情況下，節(jié)點(diǎn)沒有退出節(jié)點(diǎn)而是爆出一個(gè)警告，并且節(jié)點(diǎn)狀態(tài)也正常，警告如下：

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

集群狀態(tài)如下：

[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)

當(dāng)時(shí)覺得很奇怪，我們知道這種錯(cuò)誤即便是在主從情況下也是報(bào)錯(cuò)的 SQL 線程退出的，MGR 居然還能在線，這種情況數(shù)據(jù)已經(jīng)不同步了，應(yīng)該報(bào)錯(cuò)并且剔除節(jié)點(diǎn)才對(duì)。

二、問(wèn)題分析

隨即一些感興趣的同學(xué)馬上進(jìn)行了測(cè)試，測(cè)試結(jié)果和上面不一致，測(cè)試結(jié)果是報(bào)錯(cuò)而不是出警告如下：

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

并且這種情況表不存在的節(jié)點(diǎn)已經(jīng)被剔除掉了。下面是正常情況的節(jié)點(diǎn)狀態(tài)：

secondary 1 節(jié)點(diǎn)：[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 節(jié)點(diǎn)：[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)

那么疑問(wèn)就是為什么同樣是 MGR 一個(gè)是警告一個(gè)是錯(cuò)誤呢，并且前者還能處于正常同步狀態(tài)。不錯(cuò)看到題目就知道這里和 slave_skip_errors 參數(shù)有關(guān)。

三、測(cè)試模擬

我們知道再 Master-Slave 中如果遇到從庫(kù)表不存在肯定是報(bào)錯(cuò)的，除非設(shè)置 slave_skip_errors 參數(shù)，當(dāng)然我在線上重來(lái)沒有設(shè)置過(guò)這個(gè)參數(shù)，并且通過(guò)這個(gè)案例我們發(fā)現(xiàn)本參數(shù)對(duì) MGR 也有影響，如下測(cè)試方法：

我們?cè)?3 個(gè)節(jié)點(diǎn)都開啟 slave-skip-errors= ddl_exist_errors

如下圖：

然后搭建 3 節(jié)點(diǎn) single-primary 模式的 MGR 集群。

集群搭建正常。

然后執(zhí)行如下操作：

[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)

此時(shí) primary 節(jié)點(diǎn)是有 a_1 表的，但是因?yàn)?binlog 關(guān)閉的原因，兩個(gè) secondary 節(jié)點(diǎn)是不存在 a_1 表的。

然后我們插入數(shù)據(jù)：

[root@mysql.sock][test] insert into test.a_1 values(null, tom 
Query OK, 1 row affected (0.02 sec)

此時(shí)，primary 節(jié)點(diǎn)因?yàn)榇嬖?a_1 表，所以能夠插入，但是兩個(gè) secondary 節(jié)點(diǎn)不存在 a_1 表，所以插入是失敗的。數(shù)據(jù)產(chǎn)生不一致。正常情況下這種數(shù)據(jù)不一致會(huì)導(dǎo)致 2 個(gè) secondary 節(jié)點(diǎn)被提出集群才對(duì)。但是實(shí)際上 3 個(gè)節(jié)點(diǎn)都是正常的，集群并沒有失效。

[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)

此時(shí)去 2 個(gè) secondary 節(jié)點(diǎn)讀取 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 源碼生效點(diǎn)

這個(gè)設(shè)置在 Rows_log_event::do_apply_event 函數(shù)中生效，也就是 DML Event 開始應(yīng)用的時(shí)候生效，這是常規(guī)的 SQL 線程（或者 Worker 線程）調(diào)用的。

#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  參數(shù)控制  ignored_error_code 會(huì)將 slave_skip_errors 的參數(shù)設(shè)置讀取出來(lái)
 { 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 的執(zhí)行邏輯受到了該參數(shù)的影響。

到此，關(guān)于“分析 MySQL 的 slave_skip_errors 參數(shù)對(duì) MGR 可用性的影響”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

正文完