組複製官方翻譯四、MonitoringGroupReplication

蘭春發表於2019-01-15

https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html

使用Perfomance Schema來監控MGR

MGR主要新增了這兩個表

  • performance_schema.replication_group_member_stats
  • performance_schema.replication_group_members

關於MGR複製相關的表

  • performance_schema.replication_connection_status
  • performance_schema.replication_applier_status

MGR建立了兩個複製通道

  • group_replication_recovery: 主要是分散式恢復階段的replication changes
  • group_replication_applier：主要用作來組group的 incoming changes

18.3.1 Group Replication Server States

如果servers之間協作正常，那麼看到的state都是一樣的
但是，一旦發生網路分割槽，或者有server掛掉並脫離group，那麼不同資訊就會被報告出來
如果一個server離開了這個group，那麼它就不能上報其他server的狀態資訊
如果發生了網路分割槽，那麼仲裁法定人數就缺少，servers之間就不能很好的協作，他們只能猜測其他server的狀態並報告為unreachable

  • Table 18.1 Server State
欄位 描述 組同步
ONLINE 使用者可正常連線和執行事務 yes
RECOVERING 正在從donar伺服器同步資料 no
OFFLINE 外掛已經裝載，但是該成員不屬於任何組 no
ERROR 無論是recovery階段，還是應用事務更新，表示遇到錯誤了 no
UNREACHABLE 失聯了 no

重要：一旦例項的狀態變成了ERROR，super_read_only 會被設定成on
如果ERROR狀態消失，需要人工介入調整super_read_only=OFF

注意：MGR不是強同步的，但是最終會一致的
確切的說：事務會按照相同的順序傳送給這個group的所有成員，但是事務的執行、commit完全由成員自行處理，並不是同步進行的

18.3.2 The replication_group_members Table

performance_schema.replication_group_members 這個表主要用來監控不同成員的狀態
表裡面的資訊會自動更新，如果有新成員的加入或離開
每個成員的後設資料資訊都是共享的，可以被其他成員隨時查到
這個表主要是在比較高的層面來看複製group的一些狀態資訊，比如：

SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                               | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1     |      3306   | ONLINE       | SECONDARY   | 8.0.13         |
| group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2     |      3306   | ONLINE       | PRIMARY     | 8.0.13         |
| group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3     |      3306   | ONLINE       | SECONDARY   | 8.0.13         |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

從上面的輸出可以看出： 這個組由3個成員組成，每個成員的host、port、server-uuid一清二楚
MEMBER_STATE顯示他們都是online狀態
MEMBER_ROLE這列顯示 有2個secondaries，1個primary，因此這個group是一個single-primary 模式的GR
MEMBER_VERSION這列在某些場景對你非常重要，比如：你需要升級一個group，或者將不同mysql版本的server組合在一起的時候

18.3.3 Replication_group_member_stats

每個組的成員認證和執行事務兩步
關於認證和執行事務的一些統計資訊對明白applier queue（有多少衝突被發現了，多少事務被check了，哪些事務被commit了 等等）的增長非常有用

performance_schema.replication_group_member_stats 提供了group-level 級別的認證、統計等很多資訊
這裡面的資訊是所有成員共享的，任何成員都能查得到
值得注意的是：重新整理遠端成員的統計資訊是根據 group_replication_flow_control_period選項，所以在本地查的資訊可能互相有點延遲，有點差異是正常現象

  • Table 18.2 replication_group_member_stats
欄位 描述
Channel_name GR通道的名稱
View_id group的當前view id
Member_id 成員的uuid
Count_transactions_in_queue 需要被檢測的衝突事務數量
Count_transactions_checked 已經被檢測為衝突的事務數量
Count_conflicts_detected 沒有通過沖突檢測的事務數量
Count_transactions_rows_validating 衝突檢測資料庫的大小
Transactions_committed_all_members 所有成員都commit成功的事務集
Last_conflict_free_transaction The transaction identifier of the last conflict free transaction checked.
Count_transactions_remote_in_applier_queue 有多少遠端事務在佇列裡面需要被執行
Count_transactions_remote_applied 已經被執行過的遠端事務數量
Count_transactions_local_proposed 本地產生的需要被其他遠端成員執行的事務數量
Count_transactions_local_rollback 本地產生的事務，有多少是傳送給其他成員，後面又被自己rollback的事務數量

這些資訊對監控MGR非常重要
舉個例子：假設這個group中的一個成員延遲了，無法跟上其他成員，那麼你會看到queue裡面有很多事務
通過以上資訊，你可以決定是要移除這個成員，還是延遲在其他成員中處理這些事務來減少這個佇列中的事務數量
通過以上資訊，也能幫助你決定是否需要開啟MGR的流控措施


相關文章