問題

已知情況如下：

• 1. MySQL 版本為 8.0.21（隨 8.0 的小版本升級(jí)，MGR 參數(shù)和行為變更頻繁，需要特別注意版本號(hào)）。
• 2. MGR 架構(gòu)，一個(gè)節(jié)點(diǎn) C 網(wǎng)絡(luò)不穩(wěn)時(shí)，與其他節(jié)點(diǎn)的通訊斷開。
• 3. 通訊斷開后，一定時(shí)間內(nèi)（5 秒 + group_replication_member_expel_timeout 秒）
     其他節(jié)點(diǎn)開始質(zhì)疑節(jié)點(diǎn) C 可能掉線。在其他節(jié)點(diǎn)上，節(jié)點(diǎn) C 的狀態(tài)為 UNREACHABLE。
     其他節(jié)點(diǎn)仍然能協(xié)商并提交新事務(wù)，其協(xié)商的信息會(huì)保存在消息緩存中。
• 4. 通訊恢復(fù)后，節(jié)點(diǎn) C 會(huì)從其他節(jié)點(diǎn)的消息緩存中獲取漏掉的信息，并跟上進(jìn)度。

那么，消息緩存會(huì)被撐滿么？撐滿以后會(huì)造成什么影響？

實(shí)驗(yàn)

我們先建三節(jié)點(diǎn)的 MGR，此處忽略步驟，大家按照官方文檔進(jìn)行就行。

來看一下三節(jié)點(diǎn)的狀態(tài)：

image.png

我們知道 MGR 的消息緩存大小由 group_replication_message_cache_size 參數(shù)控，我們?cè)谌齻€(gè)節(jié)點(diǎn)上都將參數(shù)設(shè)置為最小值（128M），這樣比較容易撐滿：

image.png

我們還需要將 group_replication_member_expel_timeout 調(diào)大，使得之后通訊故障的節(jié)點(diǎn) C 不會(huì)被集群踢出。

image.png

我們需要知道消息緩存已經(jīng)用了多少，可以使用下面的命令：

image.png

現(xiàn)在我們上一些數(shù)據(jù)庫壓力，讓 MGR 發(fā)送消息，將緩存填滿：

image.png

看一下填滿后的緩存狀況：

image.png

下面，我們將 mgr-3 節(jié)點(diǎn)的網(wǎng)絡(luò)通訊斷開：

image.png

在其他節(jié)點(diǎn)查詢狀態(tài)，可以看到故障節(jié)點(diǎn)被質(zhì)疑，但沒有踢出：

image.png

同時(shí)，我們可以看到數(shù)據(jù)庫壓力仍然在繼續(xù)進(jìn)行。

現(xiàn)在，在 primary 節(jié)點(diǎn)上，我們將內(nèi)存統(tǒng)計(jì)表重置：

image.png

然后觀察內(nèi)存統(tǒng)計(jì)，查看緩存的釋放量：

image.png

等待一段時(shí)間，可以看到緩存的釋放量已經(jīng)超過緩存大小，意味著整個(gè)緩存的內(nèi)容已經(jīng)完全換過一輪：

image.png

接下來，我們恢復(fù)故障節(jié)點(diǎn)的通訊。

image.png

通訊恢復(fù)后，故障節(jié)點(diǎn)應(yīng)當(dāng)從其他節(jié)點(diǎn)的緩存中，獲取故障階段的消息，但這些消息已經(jīng)從緩存中被清掉了，我們看看故障節(jié)點(diǎn)的 error log：

image.png

可以看到，故障節(jié)點(diǎn)因?yàn)闊o法接上消息，報(bào)錯(cuò)退出集群。

而后由于 auto-rejoin 機(jī)制，故障節(jié)點(diǎn)嘗試重新加入集群，并通過 binlog 接續(xù)數(shù)據(jù)。

一些結(jié)論

本文涉及到兩個(gè) MGR 相關(guān)的參數(shù)：

1、 group_replication_member_expel_timeout

行為：當(dāng)某節(jié)點(diǎn)意外離線達(dá)到（5 秒 + group_replication_member_expel_timeout 秒）后，MGR 將其踢出集群。如果節(jié)點(diǎn)意外離線時(shí)間較短，MGR 可以自動(dòng)接續(xù)消息，仿佛節(jié)點(diǎn)從未離開。

• 優(yōu)點(diǎn)：網(wǎng)絡(luò)等發(fā)生意外時(shí)，該參數(shù)越大，越不需要人工參與，集群可自動(dòng)恢復(fù)。
• 成本：該參數(shù)越大，就需要更多的消息緩存。
• 節(jié)點(diǎn)未被踢出集群時(shí)，可以從該節(jié)點(diǎn)讀到過期數(shù)據(jù)。該參數(shù)越大，讀到過期數(shù)據(jù)的概率越大。

2、 group_replication_message_cache_size

• 優(yōu)點(diǎn)：該參數(shù)越大，可緩存的消息越多，故障節(jié)點(diǎn)恢復(fù)后自動(dòng)接續(xù)的概率越大，不需要人工參與運(yùn)維。
• 成本：消耗內(nèi)存。

小貼士

大家在選擇 MGR 參數(shù)時(shí)，建議從以下幾個(gè)方向考慮，達(dá)成平衡：

• 對(duì)環(huán)境不穩(wěn)定的容忍程度
• 自動(dòng)化程度（是否需要人工參與）
• 讀過期數(shù)據(jù)的概率
• 物理資源消耗