監控MySQL組複製

使用 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

注意，組複製是非同步的，但會達到最終的同步(譯註：即最終一致性，強一致性)。更準確地說，事務按照相同的順序投遞到全部的成員上，可是它們每一個節點對事務的執行非同步的，意味着在容許事務的提交後，每一個成員按照它們本身的步調來執行事務。