Monitoring Group Replication
如果mysql編譯了performance_schema，那麼可以使用Perfomance 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 - 此通道用於來自組的傳入更改。這是用於應用來自組的事務的通道。
以下部分描述了每個表中可用的信息。
Replication_group_member_stats
複製組中的每個成員都會驗證並應用該組提交的事務。有關驗證者和應用程序過程的統計信息對於瞭解應用程序隊列如何增長，已找到多少衝突，檢查了多少事務，到處提交了哪些事務等等非常有用。表performance_schema.replication_group_member_stats表提供與認證過程相關的以下信息(我發現實際上列名稱和文檔描述不一致)。|
Field |
Description |
|
Channel_name |
組複製通道名稱 |
|
Member_id |
當前成員的uuid |
|
Count_Transactions_in_queue |
隊列中等待衝突檢測檢查的事務數。一旦開始檢查衝突，並且他們通過檢查，他們排隊等待應用。
|
|
Count_transactions_checked |
指示已參與過沖突檢查的事務數。
|
|
Count_conflicts_detected |
指示未通過沖突檢測檢查的事務數。
|
|
Count_transactions_validating |
指示衝突檢測數據庫的當前大小
|
|
Transactions_committed_all_members |
指示已在當前視圖的所有成員上成功提交的事務。這以固定的時間間隔更新。
|
|
Last_conflict_free_transaction |
顯示最後一次無衝突的事務標識符。
|
這些字段對於監視組中連接的成員的性能很重要。例如，假設組的成員之一被延遲，並且不能與組的其他成員保持最新。在這種情況下，您可能會在隊列中看到大量的事務。基於此信息，您可以決定從組中刪除成員或延遲對組的其他成員的事務處理，從而減少排隊的事務的數量。此信息還可以幫助您決定如何調整組複製插件的流控制。
Replication_group_members
|
Field |
Description |
|
Channel_name |
組複製通道名稱 |
|
Member_id |
組成員的uuid |
|
Member_host |
組成員所在的主機 |
|
Member_port |
組成員的port |
|
Member_state |
組成員狀態(包括 ONLINE, RECOVERING, OFFLINE or UNREACHABLE) |
Replication_connection_status
|
Field |
Description |
|
Channel_name |
組複製通道名稱 |
|
Group_name |
組複製名稱 |
|
Source_UUID |
顯示組的標識符。它類似於組名稱，並且用作組複製期間生成的所有事務的UUID。 |
|
Service_state |
顯示成員是否是組的一部分。服務狀態的可能值可以是{ON，OFF和CONNECTING}; |
|
Received_transaction_set |
已由該組的此成員接收gtid集合中的事務。 |
Replication_applier_status
|
Field |
Description |
|
Channel_name |
組通道名稱 |
|
Service_state |
顯示服務是關閉還是運行 |
|
Remaining_delay |
顯示是否配置了一些應用程序延遲
|
|
Count_transactions_retries |
應用一個事務時執行的重試次數。
|
|
Received_transaction_set |
已由該組的此成員接收gtid集合中的事務。 |
Group Replication Server States
僅當view更改時，表replication_group_members纔會更新，例如，當組的配置動態更改時。服務器實例可以處於多種狀態。如果服務器正常通信，則所有服務器都報告相同的狀態。但是，如果存在網絡分區，或者服務器離開組，則可以報告不同的信息，這取決於查詢哪個服務器。注意，如果服務器已經離開組，然而顯然它不能報告關於其他服務器的狀態的更新的信息。如果有一個分區，使得仲裁丟失，服務器不能在它們之間協調。因此，他們不能猜測不同服務器的狀態。因此，不是猜測他們的狀態，而是他們報告一些服務器不可達。
|
Field |
Description |
Group Synchronized |
|
ONLINE |
成員可以作爲一個完全功能的組成員，這意味着客戶端可以連接並開始執行事務。
|
Yes |
|
RECOVERING |
該成員正在成爲該組的活躍成員，並且正在經歷恢復過程，從同步源接收狀態信息。
|
No |
|
OFFLINE |
插件已加載，但成員不屬於任何組。
|
No |
|
ERROR |
本地節點的狀態。只要恢復階段或應用更改時出現錯誤，服務器就會進入此狀態。
|
No |
|
UNREACHABLE |
每當本地故障檢測器懷疑給定服務器不可達時，因爲可能它已經崩潰或被不經意地斷開，它顯示服務器的狀態爲“不可達到”。
|
No |
請注意，組複製不是同步的，但最終是同步的。更確切地說，事務以相同的順序傳遞給所有組成員，但是它們的執行不同步，這意味着在接受事務被提交之後，每個成員以其自己的速度提交。