| Field | 描述 | 組同步 |
| ONLINE | 該成員可以作為一個具有所有功能的組成員，這意味著客戶端可以連接并開始執行事務。 | yes |
| RECOVERING | 該成員正在成為該組的有效成員，并且正處于恢復過程中，從數據源節點（數據源節點）接收狀態信息。 | no |
| OFFLINE | 插件已加載，但成員不屬于任何組。 | no |
| ERROR | 本地成員的狀態。 只要恢復階段或應用更改時出現錯誤，server就會進入此狀態。 | no |
| UNREACHABLE | 每當本地故障檢測器懷疑某個給定的server可能由于已經崩潰或被意外地斷開而不可訪問時，server的狀態顯示為“UNREACHABLE” | no |
Important
一旦實例進入ERROR狀態后，該 super_read_only選項將設置為ON。要離開ERROR 狀態，您必須手動配置實例super_read_only=OFF
需要注意的是，組復制不是同步復制，但最終是同步的。更確切地說，事務以相同的順序傳遞給所有組成員，但是它們的執行不同步，這意味著在接受事務被提交之后，每個成員以其自己的速度提交。
3.replication_group_members表
該 performance_schema.replication_group_members 表用于監視作為組成員的不同server實例的狀態。每當視圖更改時，表replication_group_members就會更新，例如，當組的配置動態更改時。在此基礎上，server成員之間交換他們的一些元數據以保持同步并繼續協作。信息在組復制成員之間共享，因此可以從任何成員查詢有關所有組成員的信息。此表可用于獲取復制組狀態的高級視圖，例如通過發出：
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 |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
根據這個結果，我們可以看到該組由三個成員組成，每個成員的主機和端口號，客戶端用來連接成員，以及成員的 server_uuid。該MEMBER_STATE列顯示了 “組成員實例狀態”之一，在該情況下，它顯示該組中的所有三個成員都是 ONLINE，并且該MEMBER_ROLE 列顯示有兩個從節點和一個主節點。因此，該組必須是以單主模式運行的。MEMBER_VERSION當您升級組并且組合中正在運行不同MySQL版本的成員時，該列可能很有用。
4. Replication_group_member_stats
復制組中的每個成員都會驗證并應用該組提交的事務。有關驗證和應用程序的統計信息對于了解申請隊列增長情況、觸發了多少沖突、檢查了多少事務、哪些事務已被所有成員提交等等非常有用。
該 performance_schema.replication_group_member_stats 表提供與認證過程相關的組級信息，以及由復制組的每個成員接收和發起的事務的統計信息。信息在組成員實例之間共享，因此可以從任何成員查詢有關所有組成員的信息。請注意，刷新遠程成員的統計信息由group_replication_flow_control_period 選項中指定的消息周期控制 ，因此這些信息可能與進行查詢的成員的本地收集的統計信息略有不同。
表 replication_group_member_stats
| field | 描述 |
| CHANNEL_NAME | 組復制通道的名稱。 |
| VIEW_ID | 此組的當前視圖標識符。 |
| Member_id | 此值為我們當前連接到的server成員的UUID。組中的每個成員具有不同的值。因為它對每個成員是唯一的，所以它也成為了一個關鍵字。 |
| Count_transactions_in_queue | 隊列中等待沖突檢測檢查的事務數。沖突檢查通過后，他們排隊等待應用。 |
| Count_transactions_checked | 表示已進行過沖突檢查的事務數。 |
| Count_conflicts_detected | 表示未通過沖突檢測檢查的事務數。 |
| Count_transactions_rows_validating | 表示沖突檢測數據庫的當前大小（每個事務經過驗證的數據庫）。 |
| Transactions_committed_all_members | 表示已在當前視圖的所有成員上成功提交的事務。 此值以固定的時間間隔更新。 |
| Last_conflict_free_transaction | 顯示最后一個經檢查無沖突的事務標識符。 |
| Count_transactions_remote_in_applier_queue | 此成員從復制組收到的等待應用的事務數。 |
| Count_transactions_remote_applied | 此成員從已應用的復制組收到的事務數。 |
| Count_transactions_local_proposed | 此成員發起并發送到復制組以進行協調的事務數。 |
| Count_transactions_local_rollback | 此成員發起的事務在發送到復制組后的回滾數。 |
這些字段對于監控組中的成員的性能很重要。例如，假設組的成員之一出現延遲，并且不能與該組的其他成員同步。在這種情況下，您可能會在隊列中看到大量的事務。基于此信息，您可以決定從組中刪除成員或延遲組中其他成員的事務處理，從而減少排隊的事務的數量。此信息還可以幫助您決定如何調整組復制插件的流控制。
以上就是簡述mysql監控組復制的詳細內容，更多關于mysql監控組復制的資料請關注腳本之家其它相關文章！
