使用 Perfomance Schema 中的表來監控組復制，假定你的MySQL編譯時已經啟動了 Performance Schema 表。組復制將添加如下兩張 P_S 表：
- performance_schema.replication_group_member_stats
- performance_schema.replication_group_members
下面這些已存在的 P_S 復制表同樣也顯示一些組復制的信息。
- performance_schema.replication_connection_status
- performance_schema.replication_applier_status
組復制插件創建的通道名稱為：
- group_replication_recovery - 該通道在分布式恢復階段進行復制。
- group_replication_applier - 該通道在組中有新寫入操作時進行復制。該通道是組中有新事務流入時使用的通道。
下面一些小節中將描述這些表中可以獲取到的信息。
1.成員狀態
復制組中的每個成員都要驗證並應用組提交的事務。關於驗證者(certifier)和應用者(applier)相關的統計數據，有助於理解應用者隊列(applier queue)是如何增長的、檢測了多少次沖突、檢測到多少個事務、哪些事務是到處提交的等等問題。
performance_schema.replication_group_member_stats表提供了以下認證相關信息：
| 字段 | 描述 |
|---|---|
| Channel_name | 組復制通道的名稱。 |
| Member_id | 當前連接到的節點的UUID。組中每個節點的UUID值都必須唯一，也正因為如此，它也提供了一種key。 |
| Count_Transactions_in_queue | 沖突檢測隊列中事務的數量。一旦探測到沖突，且通過了檢查，則它們也會排隊后被應用和提交。 |
| Count_transactions_checked | 已檢測到的沖突事務數量。 |
| Count_conflicts_detected | 未通過沖突檢查的事務數量。 |
| Count_transactions_validating | 沖突檢測數據庫的大小(根據該數據庫對每個事務進行確認) |
| Transactions_committed_all_members | 顯示在當前視圖中所有成員都成功提交的事務。該字段會在固定的時間間隔內更新。 |
| Last_conflict_free_transaction | 顯示最后檢測到的無沖突事務的事務ID。 |
這些字段對於監控連接組中成員的性能很重要。例如，假設組中某成員有些延遲，它沒有趕上組中其他成員的數據。這種情況下，你可能會看到隊列中有大量事務。根據這些信息，你可以決定是將該成員踢出組還是延遲組中其他成員處理事務，以便減少隊列中的事務數量。這些信息同樣可以幫助你決定如何調整組復制插件的流程控制。
2.組成員
該表用於監控當前視圖所跟蹤的節點狀態。或者換句話說，作為復制組的一部分，這些節點會被組成員服務跟蹤。
| 字段 | 描述 |
|---|---|
| Channel_name | 組復制的通道名稱。 |
| Member_id | 成員節點的 UUID。 |
| Member_host | 成員的地址。 |
| Member_port | 用於成員間通信的監聽端口。 |
| Member_state | 成員的狀態(可能的狀態值ONLINE, ERROR, RECOVERING,OFFLINE 或 UNREACHABLE) |
3.連接狀態
當連接到組時，該表中的一些字段顯示組復制相關的信息。例如，已從組中接收到並在應用者(applier)隊列(relay log)中排隊的事務。
| 字段 | 描述 |
|---|---|
| Channel_name | 組復制通道的名稱。 |
| Group_name | 復制組的名稱。通常它是一個有效的UUID值。 |
| Source_UUID | 組的標識符。它類似於組的名稱，它用做組復制期間產生的所有事務的UUID。 |
| Service_state | 顯示該成員是否是組的一部分。可能的值有 {ON,OFF和CONNECTING}。 |
| Received_transaction_set | 該成員已經接收到的GTID集。 |
4.applier狀態
也可以通過普通的表 replication_applier_status 來獲取組復制相關通道的狀態和線程信息。如果有很多不同工作線程正在應用(執行)事務，該worker表同樣可以用來監控每個工作線程正在做什么。
| 字段 | 描述 |
|---|---|
| Channel_name | 組復制通道的名稱。 |
| Service_state | 顯示應用(applier)服務的狀態是ON 還是 OFF。 |
| Remaining_delay | 顯示是否有applier被延遲。 |
| Count_transactions_retries | 應用事務的重試次數。 |
| Received_transaction_set | 該成員已經接收到的GTID集。 |
5.節點狀態
在每次視圖發生改變時，replication_group_members 表會隨之更新。例如，組配置被動態更改。此時，節點之間會交換它們的元數據信息並自我同步，然后協調達成一致。
組中節點可能有多種狀態。如果節點之間能正常通信，則所有節點的報告信息都是相同的。但如果發生了網絡分裂，或節點離開了組，則可能會報告不同的信息，這依賴於被查詢的是哪一個節點。注意，如果節點已經離開了組，那么顯然它不能報告其他節點相關的最新信息。如果發生了網絡分裂，以至於丟失了法定票數，則各節點將無法進行協調。因此，它們無法猜測其他節點的狀態是什么。因此，它們不會報告它們猜測出來的狀態，而是會報告節點無法到達。
| 字段 | 描述 | 組同步狀態 |
|---|---|---|
| ONLINE | 該節點已經准備好一切，可供客戶端連接，並可以執行事務。 | Yes |
| RECOVERING | 該節點正在加入組，它當前正處於分布式恢復階段，接收來自組的狀態信息。 | No |
| OFFLINE | 插件已加載，但還不是任何組中的成員。 | No |
| ERROR | 無論是恢復階段還是應用階段發生錯誤，都會出現該狀態。 | No |
| UNREACHABLE | 當本地故障探測器懷疑該節點不可到達時，將顯示該狀態。可能的原因是目標宕機、非自願離開組。 | No |
注意，組復制是非同步的，但會達到最終的同步(譯注：即最終一致性，強一致性)。更准確地說，事務按照相同的順序投遞到所有的成員上，但是它們每個節點對事務的執行非同步的，意味着在允許事務的提交后，每個成員按照它們自己的步調來執行事務。