1. 首頁 > 生活百科 > >

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

生活百科


# mysql -h 192.168.244.3. -P 3306 -ut1 -p123456ERROR 3032 (HY000): The server is currently in offline mode

  • ABORT_SERVER：關閉實例 。
    • XCom CacheXCom Cache 是 XCom 使用的消息緩存 ， 用來緩存集群節點之間交換的消息 。緩存的消息是共識協議的一部分 。如果網絡不穩定，可能會出現節點失聯的情況 。
    如果節點在一定時間（由 group_replication_member_expel_timeout 決定）內恢復正常，它會首先應用 XCom Cache 中的消息 。如果 XCom Cache 沒有它需要的所有消息，這個節點會被驅逐出集群 。驅逐出集群后，如果 group_replication_autorejoin_tries 不為 0 ， 它會重新加入集群（auto-rejoin） 。
    重新加入集群會使用 Distributed Recovery 補齊差異數據 。相比較直接使用 XCom Cache 中的消息 ， 通過 Distributed Recovery 加入集群需要的時間相對較長，過程也較復雜 ， 并且集群的性能也會受到影響 。
    所以，我們在設置 XCom Cache 的大小時，需預估 group_replication_member_expel_timeout + 5s 這段時間內的內存使用量 。如何預估，后面會介紹相關的系統表 。
    下面我們模擬下 XCom Cache 不足的場景 。
    1. 將group_replication_message_cache_size調整為最小值（128 MB），重啟組復制使其生效 。
    mysql> set global group_replication_message_cache_size=134217728;Query OK, 0 rows affected (0.00 sec)mysql> stop group_replication;Query OK, 0 rows affected (4.15 sec)mysql> start group_replication;Query OK, 0 rows affected (3.71 sec)2. 將group_replication_member_expel_timeout調整為 3600 。這樣 ， 我們才有充足的時間進行測試 。
    mysql> set global group_replication_member_expel_timeout=3600;Query OK, 0 rows affected (0.01 sec)3. 斷開 node3 與node1、node2 之間的網絡連接 。
    # iptables -A INPUT  -p tcp -s 192.168.244.10 -j DROP# iptables -A OUTPUT -p tcp -d 192.168.244.10 -j DROP# iptables -A INPUT  -p tcp -s 192.168.244.20 -j DROP# iptables -A OUTPUT -p tcp -d 192.168.244.20 -j DROP4. 反復執行大事務 。
    mysql> insert into slowtech.t1(c1) select c1 from slowtech.t1 limit 1000000;Query OK, 1000000 rows affected (10.03 sec)Records: 1000000  Duplicates: 0  Warnings: 05. 觀察錯誤日志 。
    如果 node1 或 node2 的錯誤日志中提示以下信息 ， 則意味著 node3 需要的消息已經從 XCom Cache 中逐出了 。
    [Warning] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Messages that are needed to recover node 192.168.244.30:33061 have been evicted from the message  cache. Consider resizing the maximum size of the cache by  setting group_replication_message_cache_size.'6. 查看系統表 。
    除了錯誤日志 ， 我們還可以通過系統表來判斷 XCom Cache 的使用情況 。
    mysql> select * from performance_schema.memory_summary_global_by_event_name where event_name like "%GCS_XCom::xcom_cache%"\G*************************** 1. row ***************************                  EVENT_NAME: memory/group_rpl/GCS_XCom::xcom_cache                 COUNT_ALLOC: 23678                  COUNT_FREE: 22754   SUM_NUMBER_OF_BYTES_ALLOC: 154713397    SUM_NUMBER_OF_BYTES_FREE: 28441492              LOW_COUNT_USED: 0          CURRENT_COUNT_USED: 924             HIGH_COUNT_USED: 20992    LOW_NUMBER_OF_BYTES_USED: 0CURRENT_NUMBER_OF_BYTES_USED: 126271905   HIGH_NUMBER_OF_BYTES_USED: 1461372941 row in set (0.00 sec)

    推薦閱讀