1. 首頁 > 生活百科 > >

基于案例分析 MySQL Group Replication 的故障檢測流程( 三 )

生活百科

日志的輸出包括兩部分，以空格為分界線 。
1. 當網絡連接恢復后，node3 與 node1、node2 重新建立起了連接，發現自己已經被集群驅逐，于是節點進入到 ERROR 狀態 。
mysql> select member_id,member_host,member_port,member_state,member_role from performance_schema.replication_group_members;+--------------------------------------+----------------+-------------+--------------+-------------+| member_id                            | member_host    | member_port | member_state | member_role |+--------------------------------------+----------------+-------------+--------------+-------------+| 4cbfdc79-0192-11ed-8b01-02001701bd0a | 192.168.244.30 |        3306 | ERROR        |             |+--------------------------------------+----------------+-------------+--------------+-------------+1 row in set (0.00 sec)節點進入到 ERROR 狀態，會自動設置為只讀，即日志中看到的 super_read_only=ON 。注意 ， ERROR 狀態的節點設置為只讀是默認行為 ， 與后面提到的 group_replication_exit_state_action 參數無關 。
2. 如果group_replication_autorejoin_tries不為 0，對于 ERROR 狀態的節點，會自動重試 ， 重新加入集群（auto-rejoin） 。重試的次數由 group_replication_autorejoin_tries 決定，從 MySQL 8.0.21 開始，默認為 3 。重試的時間間隔是 5min 。重試成功后，會進入到分布式恢復階段 。
接下來看看 node1 的日志 。
2022-07-31T13:07:39.555613-00:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to 192.168.244.10:3306, 192.168.244.20:3306, 192.168.244.30:3306 on view 16592724636525403:4.'2022-07-31T13:07:40.732568-00:00 0 [System] [MY-011492] [Repl] Plugin group_replication reported: 'The member with address 192.168.244.30:3306 was declared online within the replication group.'node3 又重新加入到集群中 。
故障檢測流程結合上面的案例，我們來看看 Group Repliction 的故障檢測流程 。

  1. 集群中每個節點都會定期（每秒 1 次）向其它節點發送心跳信息 。如果在 5s 內（固定值，無參數調整）沒有收到其它節點的心跳信息，則會將該節點標記為可疑節點，同時會將該節點的狀態設置為 UNREACHABLE。如果集群中有等于或超過 1/2 的節點顯示為 UNREACHABLE ，則該集群不能對外提供寫服務 。
  2. 如果在group_replication_member_expel_timeout（從 MySQL 8.0.21 開始 ， 該參數的默認值為 5，單位 s，最大可設置值為3600，即 1 小時）時間內 ， 可疑節點恢復正常 ， 則會直接應用 XCom Cache 中的消息 。XCom Cache 的大小由group_replication_message_cache_size 決定 ， 默認是 1G 。
  3. 如果在group_replication_member_expel_timeout時間內，可疑節點沒有恢復正常，則會被驅逐出集群 。
  4. 而少數派節點呢，不會自動離開集群 ， 它會一直維持當前的狀態，直到：
    • 網絡恢復正常 。
    • 達到 group_replication_unreachable_majority_timeout 的限制 。注意，該參數的起始計算時間是連接斷開 5s 之后，不是可疑節點被驅逐出集群的時間 。該參數默認為 0 。
  5. 無論哪種情況 ， 都會觸發：
    • 節點狀態從 ONLINE 切換到 ERROR。
    • 回滾當前被阻塞的寫操作 。
      mysql> delete from slowtech.t1 where id=1;ERROR 3100 (HY000): Error on observer while running replication hook 'before_commit'.
  6. ERROR 狀態的節點會自動設置為只讀 。
  7. 如果group_replication_autorejoin_tries不為 0，對于 ERROR 狀態的節點，會自動重試，重新加入集群（auto-rejoin） 。
  8. 如果group_replication_autorejoin_tries為 0 或重試失敗，則會執行 group_replication_exit_state_action 指定的操作 。可選的操作有：