分析MySQL的slave_skip_errors參數對MGR可用性的影響

這篇文章主要介紹“分析MySQL的slave_skip_errors參數對MGR可用性的影響”，在日常操作中，相信很多人在分析MySQL的slave_skip_errors參數對MGR可用性的影響問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”分析MySQL的slave_skip_errors參數對MGR可用性的影響”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

10年積累的成都網站設計、成都做網站經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先網站設計后付款的網站建設流程，更有江源免費網站建設讓你可以放心的選擇與我們合作。

一、案例描述

MGR在遇到表不存在的情況下，節(jié)點沒有退出節(jié)點而是爆出一個警告，并且節(jié)點狀態(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)

當時覺得很奇怪，我們知道這種錯誤即便是在主從情況下也是報錯的SQL線程退出的，MGR居然還能在線，這種情況數據已經不同步了，應該報錯并且剔除節(jié)點才對。

二、問題分析

隨即一些感興趣的同學馬上進行了測試，測試結果和上面不一致，測試結果是報錯而不是出警告如下：

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é)點已經被剔除掉了。下面是正常情況的節(jié)點狀態(tài)：

secondary 1節(jié)點：
[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é)點：
[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一個是警告一個是錯誤呢，并且前者還能處于正常同步狀態(tài)。不錯看到題目就知道這里和slave_skip_errors參數有關。

三、測試模擬

我們知道再Master-Slave中如果遇到從庫表不存在肯定是報錯的，除非設置slave_skip_errors參數，當然我在線上重來沒有設置過這個參數，并且通過這個案例我們發(fā)現本參數對MGR也有影響，如下測試方法：

我們在3個節(jié)點都開啟slave-skip-errors= ddl_exist_errors

如下圖：

分析MySQL的slave_skip_errors參數對MGR可用性的影響

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

分析MySQL的slave_skip_errors參數對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)

此時primary節(jié)點是有a_1表的，但是因為binlog關閉的原因，兩個secondary節(jié)點是不存在a_1表的。

然后我們插入數據：

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

此時，primary節(jié)點因為存在a_1表，所以能夠插入，但是兩個secondary節(jié)點不存在a_1表，所以插入是失敗的。數據產生不一致。正常情況下這種數據不一致會導致2個secondary節(jié)點被提出集群才對。但是實際上3個節(jié)點都是正常的，集群并沒有失效。

[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節(jié)點讀取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開始應用的時候生效，這是常規(guī)的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的執(zhí)行邏輯受到了該參數的影響。

到此，關于“分析MySQL的slave_skip_errors參數對MGR可用性的影響”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

文章題目：分析MySQL的slave_skip_errors參數對MGR可用性的影響
文章起源：http://bm7419.com/article40/psdpeo.html

成都網站建設公司_創(chuàng)新互聯，為您提供App開發(fā)、定制開發(fā)、企業(yè)建站、網站營銷、網站內鏈、動態(tài)網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯

h5響應式網站建設