MySQL組復制MGR（三）-- 組復制監控

如果MySQL啟用了性能監控數據庫performance_schema，則在搭建組復制的時候會創建2個表：

• performance_schema.replication_group_members
• performance_schema.replication_group_member_stats

這些performance_schema里面的表也顯示組復制的信息：

• performance_schema.replication_connection_status
• performance_schema.replication_applier_status

由復制插件創建的復制通道被命名為：

• group_replication_recovery:此通道用於與分布式恢復階段相關的復制更改
• group_replication_applier：此通道用於來自組的傳入更改。

下面主要介紹前2個表。

（1）performance_schema.replication_group_members

該表用於監控MySQL組成員的狀態信息

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
 | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
 | group_replication_applier | 533fe6ba-bcdf-11ea-9516-000c295111ae | mgr-node1   |        3306 | ONLINE       |
 | group_replication_applier | 5ca45641-bcdd-11ea-918e-000c29fa726d | mgr-node2   |        3306 | ONLINE       |
 | group_replication_applier | 62ad32e3-bcdd-11ea-9bbb-000c2978d7f6 | mgr-node3   |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

這里需要關注組成員的數量已經成員狀態（MEMBER_STATE）：

狀態	描述	組同步
ONLINE	該成員可以作為一個具有所有功能的組成員，客戶端可以開始連接執行事務	是
RECOVERING	該成員正在恢復成為一個活躍的組成員	否
OFFLINE	插件已加載但成員不屬於任何組	否
ERROR	恢復階段或者應用更改時出現錯誤，server就會進入此狀態	否
UNREACHABLE	每當本地故障檢測器懷疑給定服務器無法訪問時（例如由於非自願斷開連接），它將顯示該服務器的狀態為UNREACHABLE。	否

（2）performance_schema.replication_group_member_stats

復制組中的每個成員都認證並應用該組接收的事務，該表記錄了認證過程相關的信息，如檢查了多少事務、發現了多少沖突。

mysql> select * from performance_schema.replication_group_member_stats \G
*************************** 1. row ***************************
                      CHANNEL_NAME: group_replication_applier
                           VIEW_ID: 15956427854145598:3
                         MEMBER_ID: 533fe6ba-bcdf-11ea-9516-000c295111ae
       COUNT_TRANSACTIONS_IN_QUEUE: 0
        COUNT_TRANSACTIONS_CHECKED: 20000
          COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 2
TRANSACTIONS_COMMITTED_ALL_MEMBERS: dc04ba77-bcf2-11ea-85bf-000c295111ae:1-276051:1000003-1005707
    LAST_CONFLICT_FREE_TRANSACTION: dc04ba77-bcf2-11ea-85bf-000c295111ae:276051

各個字段的含義：

CHANNEL_NAME: 組復制通道的名稱
VIEW_ID:
MEMBER_ID: 成員的id
COUNT_TRANSACTIONS_IN_QUEUE: 隊列中等待沖突檢測的事務數，沖突檢測后，排隊等待應用
COUNT_TRANSACTIONS_CHECKED: 已進行沖突檢查的事務數量
COUNT_CONFLICTS_DETECTED: 未通過沖突檢查的事務數量
COUNT_TRANSACTIONS_ROWS_VALIDATING: 表示沖突檢測數據庫的當前大小
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 表示在當前視圖的成員上成功提交的事務
LAST_CONFLICT_FREE_TRANSACTION: 顯示最后一個檢查無沖突的事務標識符

這些信息對於組性能監控非常重要，例如，假設組成員之一總是報出大量事務在隊列中，這意味着該成員數據存在延遲，不能保持最新。基於這些信息，你可以決定去移除該成員，或者延遲其它節點的事務處理，從而減小排隊的影響。

【完】