【MySQL】監控組複製

原文：https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html
譯者：kun
最近在翻譯MySQL8.0官方文檔 本文是第18.3“監控組複製”部分。

18.3 監控組複製

假設MySQL已經在啓用了性能模式的情況下編譯，使用Perfomance Schema表監控組複製。組複製添加以下表：

• performance_schema.replication_group_member_stats
• performance_schema.replication_group_members

這些現有的Perfomance Schema複製表也顯示有關組複製的信息：

• performance_schema.replication_connection_status 顯示有關組複製的信息，例如，已從組接收並在應用程序隊列中排隊的事務（中繼日誌）。
• performance_schema.replication_applier_status 顯示與組複製相關的通道和線程的狀態，如果有許多不同的工作線程應用事務，那麼這個表也可用於監視每個工作線程正在執行的操作。

Group Replication插件創建的複製通道命名爲：

• group_replication_recovery - 此通道用於與分佈式恢復階段相關的複製更改。
• group_replication_applier - 此通道用於來自組的傳入更改。並且應用直接來自組的事務的通道。

以下部分描述了每個表中可用的信息。

18.3.1 組成員實例狀態

組中的server實例可以處於多種狀態。如果server都正常通信，則所有server都報告相同的狀態。但是，如果存在網絡分隔，或者組成員離開組，則可能報告不同的信息，這取決於查詢了哪個server。要注意的是，如果某個組成員已經離開組，那麼顯然它不能報告關於其他server狀態的最新信息。如果發生網絡分隔，如果超出仲裁數量的server都斷開了，那麼server之間將不能相互協作。因此，他們無法得知不同server成員的狀態。因此，他們會報告一些server不可訪問，而不是猜測他們的狀態。

表18.1 Server State

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

需要注意的是，組複製不是同步複製，但最終是同步的。更確切地說，事務以相同的順序傳遞給所有組成員，但是它們的執行不同步，這意味着在接受事務被提交之後，每個成員以其自己的速度提交。

18.3.2 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列顯示了 第18.3.1節“組成員實例狀態”之一，在該情況下，它顯示該組中的所有三個成員都是 ONLINE，並且該MEMBER_ROLE 列顯示有兩個從節點和一個主節點。因此，該組必須是以單主模式運行的。MEMBER_VERSION當您升級組並且組合中正在運行不同MySQL版本的成員時，該列可能很有用。請參見 第18.3.1節“組成員實例狀態” 獲得更多信息。

有關Member_host 值及其對分佈式恢復過程的影響的更多信息，請參見 第18.2.1.3節“用戶憑據”。

18.3.3 Replication_group_member_stats

複製組中的每個成員都會驗證並應用該組提交的事務。有關驗證和應用程序的統計信息對於瞭解申請隊列增長情況、觸發了多少衝突、檢查了多少事務、哪些事務已被所有成員提交等等非常有用。

該 performance_schema.replication_group_member_stats 表提供與認證過程相關的組級信息，以及由複製組的每個成員接收和發起的事務的統計信息。信息在組成員實例之間共享，因此可以從任何成員查詢有關所有組成員的信息。請注意，刷新遠程成員的統計信息由group_replication_flow_control_period 選項中指定的消息週期控制 ，因此這些信息可能與進行查詢的成員的本地收集的統計信息略有不同。

表18.2 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	此成員發起的事務在發送到複製組後的回滾數。

這些字段對於監控組中的成員的性能很重要。例如，假設組的成員之一出現延遲，並且不能與該組的其他成員同步。在這種情況下，您可能會在隊列中看到大量的事務。基於此信息，您可以決定從組中刪除成員或延遲組中其他成員的事務處理，從而減少排隊的事務的數量。此信息還可以幫助您決定如何調整組複製插件的流控制。