故障檢測與網絡分區| 深入淺出MGR

本文介紹MGR的故障檢測機制，以及發生網絡分區後如何處理。

1. 故障檢測

當MGR中個別節點與其他節點通信異常時，就會觸發故障檢測機制，經過多數派節點投票判斷後再決定是否將其驅逐出MGR。

發生故障時，只有當多數派節點存活前提下，故障檢測機制才能工作正常，使得MGR恢復可用性；當多數派節點本身已經異常的時候，MGR是無法自行恢復的，需要人為介入。

MGR中，各節點間會定期交換消息，當超過5秒（在MySQL中是固定5秒，在GreatSQL中新增選項group_replication_communication_flp_timeout​可配置）還沒收到某個節點的任何消息時，就會將這個節點標記為可疑狀態。MGR各正常存活節點會對可疑節點每隔15秒檢測一次（在GreatSQL中，調整為每隔2秒檢測，效率更高，下面再介紹），當確認可疑節點在超過group_replication_member_expel_timeout秒超時閾值後，再將該節點驅逐出MGR。

需要注意的是，選項group_replication_member_expel_timeout​從MySQL 8.0.21開始，默認值為5。在MySQL 8.0.21之前，默認值為0。在<= MySQL 8.0.20 的版本中，group_replication_member_expel_timeout默認值為0，也就是當某節點被判定為可疑狀態後，會被立即驅逐。在MySQL 5.7中，沒有該選項，行為模式也是一樣的。

在MySQL中，MGR故障檢測是由獨立線程來完成的，該線程每隔15秒（MySQL在源碼中硬編碼定義了SUSPICION_PROCESSING_THREAD_PERIOD = 15）進行一次檢查。因此，節點發生故障時，極端情況下，可能要耗費5（5秒沒發送消息，被判定為可疑節點） + 15（SUSPICION_PROCESSING_THREAD_PERIOD） + 5（group_replication_member_expel_timeout） = 25秒才能驅逐該節點。最好的情況下，最快5 + 5 = 10秒後即可驅逐該節點。

在GreatSQL中對此進行了優化，新增選項group_replication_communication_flp_timeout​（默認值5，最小3，最大60） 用於定義節點超過多少秒沒發消息會被判定為可疑。此外，還修改了硬編碼SUSPICION_PROCESSING_THREAD_PERIOD = 2​，也就是故障檢測線程每2秒（而非15秒）就會檢查一次。因此在GreatSQL中，最快5（group_replication_communication_flp_timeout） + 5（group_replication_member_expel_timeout） = 10秒​完成驅逐，最慢5 + 5 + 2（SUSPICION_PROCESSING_THREAD_PERIOD） = 12秒完成驅逐。

在網絡條件不好的情況下，建議適當加大group_replication_member_expel_timeout 值，避免網絡波動造成節點頻繁被驅逐。不過也要注意另一個風險，見這篇文章所述：技術分享| 為什麼MGR一致性模式不推薦AFTER

存活的節點會把被驅逐的節點從成員列表中刪除，但被驅逐的節點自身可能還沒“意識”到（可能只是因為臨時短時間的網絡異常），在狀態恢復後，該節點會先收到一條包含該節點已被驅逐出MGR的新視圖信息，而後再重新加入MGR。被驅逐的節點會嘗試group_replication_autorejoin_tries次重新加入MGR。

選項group_replication_exit_state_action​定義了被驅逐節點之後的行為模式，默認是設置為super_read_only = ON，進入只讀模式。

2. 少數派成員失聯時

當集群中的少數派成員失聯時（Unreachable），默認不會自動退出MGR集群。這時可以設置group_replication_unreachable_majority_timeout​，當少數派節點和多數派節點失聯超過該閾值時，少數派節點就會自動退出MGR集群。如果設置為0，則會立即退出，而不再等待。節點退出集群時，相應的事務會被回滾，然後節點狀態變成ERROR，並執行選項group_replication_exit_state_action​定義的後續行為模式。如果設置了group_replication_autorejoin_tries，也會再自動嘗試重新加入MGR集群。

3. 多數派成員失聯時

當多數派節點也失聯時（Unreachable），例如在一個3節點的MGR集群中，有2個節點失聯了，剩下的1個節點不能成為多數派，也就無法對新事務請求做出決策，這種情況就是發生了網絡分區（腦裂）。也就是一個MGR集群分裂成兩個或多個區域，也因此缺少多數派，這種情況下，MGR集群無法提供寫入服務。

此時需要人工介入，通過設置group_replication_force_members​強行指定新的成員列表。例如MGR集群由3個節點組成，其中兩個節點都意外失聯了，僅剩一個節點存活，此時就需要手動設置group_replication_force_members強行指定成員列表，也就是只有最後存活的節點。

兩個重要提醒：

使用該方法基本上是最後迫不得已的選擇，因此需要非常謹慎。若使用不當，可能會造成一個人為的腦裂場景，或者造成整個系統被完全阻塞。也有可能會選錯新的節點列表。強制設定新的節點列表並解除MGR阻塞後，記得再將該選項值清空，否則無法再次執行START GROUP_REPLICATION。

4. Xcom cache

當有節點處於可疑狀態時，在它被確定踢出MGR集群之前，事務會緩存在其他節點的Xcom cache中。這個cache對應選項group_replication_message_cache_size。當可疑節點短時內又恢復後，就會先從Xcom cache中讀取記錄進行恢復，然後再進行分佈式恢復。因此，在網絡不太穩定或併發事務較大，且物理內存也足夠的場景裡，可以適當加大Xcom cache size；反之，在物理內存較小，或者網絡較為穩定的場景裡，不應設置太大，降低發生OOM的風險。

在MySQL 5.7裡，Xcom cache size最大值1G，且不可動態調整。從MySQL 8.0開始，可對其動態調整。在<= MySQL 8.0.20的版本中，最小值1G。在>= MySQL 8.0.21的版本中，最小值128M。

可以執行下面的SQL查看當前Xcom cache消耗情況：

[root@GreatSQL]> SELECT * FROM performance_schema.memory_summary_global_by_event_name
  WHERE EVENT_NAME LIKE ‘memory/group_rpl/GCS_XCom::xcom_cache';
1.
2.

在MySQL中，是動態按需分配Xcom cache的，如果太多有空閒，就釋放；如果不夠用，再動態分配更多內存，一次分配大概250000個cache item，很容易造成約150ms的響應延遲。也就是說，會隨著事務多少的變化而可能頻繁產生響應延遲。

在GreatSQL中，對Xcom cache採用了靜態化分配機制，即一開始就預分配約1GB內存用於xcom cache，這可以避免前面提到的響應延遲抖動風險，不過“副作用”是mysqld進程所佔用的內存會比原來多，在內存特別緊張的服務器上不太適合。

5. 網絡分區

在MGR裡，事務是需要經過多數派節點達成一致性共識（要么都提交，要么都回滾）。同樣的，前面提到的節點間通信消息也是需要在多數派節點間達成共識。當MGR中的多數派節點失聯時，就無法就此形成共識，也無法滿足多數派投票/仲裁要求，此時MGR將拒絕寫事務請求。這種情況，也稱為網絡分區，及一個MGR集群分裂成兩個或多個分區，彼此間相互無法連通，任何一個分區中的節點都不能達成多數派。

可能Primary節點會因為網絡分區時被踢出MGR集群，它在重新加回時，可能會因為本地有此前還沒來得及同步到其他節點的事務，而造成本地有更多事務，會報告類似下面的錯誤：

This member has more executed transactions than those present in the group. Local transactions: xx:1-300917674 > Group transactions: xx:1-300917669
1.

此時需要人工介入處理，選擇哪個節點作為最新的Primary節點。

6. 小結

本文介紹了MGR的故障檢測機制、Xcom cache，什麼是網絡分區，以及發生故障時都有什麼影響，如何恢復故障等。