本文介紹MGR的故障檢測(cè)機(jī)制，以及發(fā)生網(wǎng)絡(luò)分區(qū)后如何處理。

1. 故障檢測(cè)

當(dāng)MGR中個(gè)別節(jié)點(diǎn)與其他節(jié)點(diǎn)通信異常時(shí)，就會(huì)觸發(fā)故障檢測(cè)機(jī)制，經(jīng)過(guò)多數(shù)派節(jié)點(diǎn)投票判斷后再?zèng)Q定是否將其驅(qū)逐出MGR。

發(fā)生故障時(shí)，只有當(dāng)多數(shù)派節(jié)點(diǎn)存活前提下，故障檢測(cè)機(jī)制才能工作正常，使得MGR恢復(fù)可用性；當(dāng)多數(shù)派節(jié)點(diǎn)本身已經(jīng)異常的時(shí)候，MGR是無(wú)法自行恢復(fù)的，需要人為介入。

MGR中，各節(jié)點(diǎn)間會(huì)定期交換消息，當(dāng)超過(guò)5秒（在MySQL中是固定5秒，在GreatSQL中新增選項(xiàng)group_replication_communication_flp_timeout?可配置）還沒(méi)收到某個(gè)節(jié)點(diǎn)的任何消息時(shí)，就會(huì)將這個(gè)節(jié)點(diǎn)標(biāo)記為可疑狀態(tài)。MGR各正常存活節(jié)點(diǎn)會(huì)對(duì)可疑節(jié)點(diǎn)每隔15秒檢測(cè)一次（在GreatSQL中，調(diào)整為每隔2秒檢測(cè)，效率更高，下面再介紹），當(dāng)確認(rèn)可疑節(jié)點(diǎn)在超過(guò)group_replication_member_expel_timeout秒超時(shí)閾值后，再將該節(jié)點(diǎn)驅(qū)逐出MGR。

需要注意的是，選項(xiàng)group_replication_member_expel_timeout?從MySQL 8.0.21開(kāi)始，默認(rèn)值為5。在MySQL 8.0.21之前，默認(rèn)值為0。在 <= MySQL 8.0.20 的版本中，group_replication_member_expel_timeout默認(rèn)值為 0，也就是當(dāng)某節(jié)點(diǎn)被判定為可疑狀態(tài)后，會(huì)被立即驅(qū)逐。在MySQL 5.7中，沒(méi)有該選項(xiàng)，行為模式也是一樣的。

在MySQL中，MGR故障檢測(cè)是由獨(dú)立線程來(lái)完成的，該線程每隔15秒（MySQL在源碼中硬編碼定義了SUSPICION_PROCESSING_THREAD_PERIOD = 15）進(jìn)行一次檢查。因此，節(jié)點(diǎn)發(fā)生故障時(shí)，極端情況下，可能要耗費(fèi) 5（5秒沒(méi)發(fā)送消息，被判定為可疑節(jié)點(diǎn)） + 15（SUSPICION_PROCESSING_THREAD_PERIOD） + 5（group_replication_member_expel_timeout） = 25秒 才能驅(qū)逐該節(jié)點(diǎn)。最好的情況下，最快 5 + 5 = 10秒 后即可驅(qū)逐該節(jié)點(diǎn)。

在GreatSQL中對(duì)此進(jìn)行了優(yōu)化，新增選項(xiàng)group_replication_communication_flp_timeout?（默認(rèn)值5，最小3，最大60） 用于定義節(jié)點(diǎn)超過(guò)多少秒沒(méi)發(fā)消息會(huì)被判定為可疑。此外，還修改了硬編碼SUSPICION_PROCESSING_THREAD_PERIOD = 2?，也就是故障檢測(cè)線程每2秒（而非15秒）就會(huì)檢查一次。因此在GreatSQL中，最快5（group_replication_communication_flp_timeout） + 5（group_replication_member_expel_timeout） = 10秒?完成驅(qū)逐，最慢5 + 5 + 2（SUSPICION_PROCESSING_THREAD_PERIOD） = 12秒完成驅(qū)逐。

在網(wǎng)絡(luò)條件不好的情況下，建議適當(dāng)加大 group_replication_member_expel_timeout 值，避免網(wǎng)絡(luò)波動(dòng)造成節(jié)點(diǎn)頻繁被驅(qū)逐。不過(guò)也要注意另一個(gè)風(fēng)險(xiǎn)，見(jiàn)這篇文章所述：技術(shù)分享 | 為什么MGR一致性模式不推薦AFTER

存活的節(jié)點(diǎn)會(huì)把被驅(qū)逐的節(jié)點(diǎn)從成員列表中刪除，但被驅(qū)逐的節(jié)點(diǎn)自身可能還沒(méi)“意識(shí)”到（可能只是因?yàn)榕R時(shí)短時(shí)間的網(wǎng)絡(luò)異常），在狀態(tài)恢復(fù)后，該節(jié)點(diǎn)會(huì)先收到一條包含該節(jié)點(diǎn)已被驅(qū)逐出MGR的新視圖信息，而后再重新加入MGR。被驅(qū)逐的節(jié)點(diǎn)會(huì)嘗試group_replication_autorejoin_tries次重新加入MGR。

選項(xiàng)group_replication_exit_state_action?定義了被驅(qū)逐節(jié)點(diǎn)之后的行為模式，默認(rèn)是設(shè)置為super_read_only = ON，進(jìn)入只讀模式。

2. 少數(shù)派成員失聯(lián)時(shí)

當(dāng)集群中的少數(shù)派成員失聯(lián)時(shí)（Unreachable），默認(rèn)不會(huì)自動(dòng)退出MGR集群。這時(shí)可以設(shè)置group_replication_unreachable_majority_timeout?，當(dāng)少數(shù)派節(jié)點(diǎn)和多數(shù)派節(jié)點(diǎn)失聯(lián)超過(guò)該閾值時(shí)，少數(shù)派節(jié)點(diǎn)就會(huì)自動(dòng)退出MGR集群。如果設(shè)置為0，則會(huì)立即退出，而不再等待。節(jié)點(diǎn)退出集群時(shí)，相應(yīng)的事務(wù)會(huì)被回滾，然后節(jié)點(diǎn)狀態(tài)變成ERROR，并執(zhí)行選項(xiàng)group_replication_exit_state_action?定義的后續(xù)行為模式。如果設(shè)置了group_replication_autorejoin_tries，也會(huì)再自動(dòng)嘗試重新加入MGR集群。

3. 多數(shù)派成員失聯(lián)時(shí)

當(dāng)多數(shù)派節(jié)點(diǎn)也失聯(lián)時(shí)（Unreachable），例如在一個(gè)3節(jié)點(diǎn)的MGR集群中，有2個(gè)節(jié)點(diǎn)失聯(lián)了，剩下的1個(gè)節(jié)點(diǎn)不能成為多數(shù)派，也就無(wú)法對(duì)新事務(wù)請(qǐng)求做出決策，這種情況就是發(fā)生了網(wǎng)絡(luò)分區(qū)（腦裂）。也就是一個(gè)MGR集群分裂成兩個(gè)或多個(gè)區(qū)域，也因此缺少多數(shù)派，這種情況下，MGR集群無(wú)法提供寫入服務(wù)。

此時(shí)需要人工介入，通過(guò)設(shè)置group_replication_force_members?強(qiáng)行指定新的成員列表。例如MGR集群由3個(gè)節(jié)點(diǎn)組成，其中兩個(gè)節(jié)點(diǎn)都意外失聯(lián)了，僅剩一個(gè)節(jié)點(diǎn)存活，此時(shí)就需要手動(dòng)設(shè)置group_replication_force_members強(qiáng)行指定成員列表，也就是只有最后存活的節(jié)點(diǎn)。

兩個(gè)重要提醒：

使用該方法基本上是最后迫不得已的選擇，因此需要非常謹(jǐn)慎。若使用不當(dāng)，可能會(huì)造成一個(gè)人為的腦裂場(chǎng)景，或者造成整個(gè)系統(tǒng)被完全阻塞。也有可能會(huì)選錯(cuò)新的節(jié)點(diǎn)列表。 強(qiáng)制設(shè)定新的節(jié)點(diǎn)列表并解除MGR阻塞后，記得再將該選項(xiàng)值清空，否則無(wú)法再次執(zhí)行START GROUP_REPLICATION。

4. Xcom cache

當(dāng)有節(jié)點(diǎn)處于可疑狀態(tài)時(shí)，在它被確定踢出MGR集群之前，事務(wù)會(huì)緩存在其他節(jié)點(diǎn)的Xcom cache中。這個(gè)cache對(duì)應(yīng)選項(xiàng)group_replication_message_cache_size。當(dāng)可疑節(jié)點(diǎn)短時(shí)內(nèi)又恢復(fù)后，就會(huì)先從Xcom cache中讀取記錄進(jìn)行恢復(fù)，然后再進(jìn)行分布式恢復(fù)。因此，在網(wǎng)絡(luò)不太穩(wěn)定或并發(fā)事務(wù)較大，且物理內(nèi)存也足夠的場(chǎng)景里，可以適當(dāng)加大Xcom cache size；反之，在物理內(nèi)存較小，或者網(wǎng)絡(luò)較為穩(wěn)定的場(chǎng)景里，不應(yīng)設(shè)置太大，降低發(fā)生OOM的風(fēng)險(xiǎn)。

在MySQL 5.7里，Xcom cache size最大值1G，且不可動(dòng)態(tài)調(diào)整。從MySQL 8.0開(kāi)始，可對(duì)其動(dòng)態(tài)調(diào)整。在 <= MySQL 8.0.20的版本中，最小值1G。在>= MySQL 8.0.21的版本中，最小值128M。

可以執(zhí)行下面的SQL查看當(dāng)前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';

在MySQL中，是動(dòng)態(tài)按需分配Xcom cache的，如果太多有空閑，就釋放；如果不夠用，再動(dòng)態(tài)分配更多內(nèi)存，一次分配大概250000個(gè)cache item，很容易造成約150ms的響應(yīng)延遲。也就是說(shuō)，會(huì)隨著事務(wù)多少的變化而可能頻繁產(chǎn)生響應(yīng)延遲。

在GreatSQL中，對(duì)Xcom cache采用了靜態(tài)化分配機(jī)制，即一開(kāi)始就預(yù)分配約1GB內(nèi)存用于xcom cache，這可以避免前面提到的響應(yīng)延遲抖動(dòng)風(fēng)險(xiǎn)，不過(guò)“副作用”是mysqld進(jìn)程所占用的內(nèi)存會(huì)比原來(lái)多，在內(nèi)存特別緊張的服務(wù)器上不太適合。

5. 網(wǎng)絡(luò)分區(qū)

在MGR里，事務(wù)是需要經(jīng)過(guò)多數(shù)派節(jié)點(diǎn)達(dá)成一致性共識(shí)（要么都提交，要么都回滾）。同樣的，前面提到的節(jié)點(diǎn)間通信消息也是需要在多數(shù)派節(jié)點(diǎn)間達(dá)成共識(shí)。當(dāng)MGR中的多數(shù)派節(jié)點(diǎn)失聯(lián)時(shí)，就無(wú)法就此形成共識(shí)，也無(wú)法滿足多數(shù)派投票/仲裁要求，此時(shí)MGR將拒絕寫事務(wù)請(qǐng)求。這種情況，也稱為網(wǎng)絡(luò)分區(qū)，及一個(gè)MGR集群分裂成兩個(gè)或多個(gè)分區(qū)，彼此間相互無(wú)法連通，任何一個(gè)分區(qū)中的節(jié)點(diǎn)都不能達(dá)成多數(shù)派。

可能Primary節(jié)點(diǎn)會(huì)因?yàn)榫W(wǎng)絡(luò)分區(qū)時(shí)被踢出MGR集群，它在重新加回時(shí)，可能會(huì)因?yàn)楸镜赜写饲斑€沒(méi)來(lái)得及同步到其他節(jié)點(diǎn)的事務(wù)，而造成本地有更多事務(wù)，會(huì)報(bào)告類似下面的錯(cuò)誤：

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

此時(shí)需要人工介入處理，選擇哪個(gè)節(jié)點(diǎn)作為最新的Primary節(jié)點(diǎn)。

6. 小結(jié)

本文介紹了MGR的故障檢測(cè)機(jī)制、Xcom cache，什么是網(wǎng)絡(luò)分區(qū)，以及發(fā)生故障時(shí)都有什么影響，如何恢復(fù)故障等。

參考資料、文檔

MySQL 8.0 Reference Manual(https://dev.mysql.com/doc/refman/8.0/en/group-replication.html)

數(shù)據(jù)庫(kù)內(nèi)核開(kāi)發(fā) - 溫正湖(https://www.zhihu.com/column/c_206071340)

Group Replication原理 - 宋利兵(https://mp.weixin.qq.com/s/1iO-KISAU1HLSzEVLrxG9g)