本文介紹MGR中的流量控制（流控）是怎么工作的。

1. MGR流控

在MGR中，各個節(jié)點的事務(wù)處理能力不盡相同，這就可能會造成個別節(jié)點上存在事務(wù)復(fù)制延遲，在這些節(jié)點上就有可能讀取到舊事務(wù)數(shù)據(jù)。復(fù)制延遲的另一個風(fēng)險時，當(dāng)有新節(jié)點加入時，需要選擇一個節(jié)點作為donor節(jié)點，若該節(jié)點存在延遲，則可能最后會選中Primary節(jié)點，影響事務(wù)寫入性能。還有，當(dāng)某節(jié)點中堆積大量延遲事務(wù)隊列時，也很容易造成該節(jié)點發(fā)生OOM風(fēng)險。

(資料圖片僅供參考)

綜上幾點，為了避免個別節(jié)點存在嚴重的事務(wù)復(fù)制延遲及其他風(fēng)險，必要時可以采用流量控制（下面簡稱“流控”）來避免/緩解這個問題，降低節(jié)點間的事務(wù)延遲差距。

MGR流控有幾個要點：

基于事務(wù)認證隊列及等待被applied的relay log隊列這兩個隊列（group_replication_flow_control_applier_threshold、group_replication_flow_control_certifier_threshold，默認值均為：25000），實行配額控制。

啟用流控（group_replication_flow_control_mode，默認值：QUOTA）后，當(dāng)任何一個隊列大小超過設(shè)定閾值（配額）后，就會觸發(fā)流控機制。

只影響啟用流控的節(jié)點，不影響MGR中的其他節(jié)點（在PXC里是所有節(jié)點同時被流控影響）。

當(dāng)設(shè)置流控配額百分比（group_replication_flow_control_member_quota_percent）時，會在多個啟用流控的Primary節(jié)點間平攤配額。

流控只針對寫事務(wù)，不影響只讀事務(wù)。

觸發(fā)流控后，會暫緩事務(wù)寫入請求，在group_replication_flow_control_period（默認值：1）秒后再次檢查是否還超過閾值。如果還是超過則繼續(xù)流控，否則的話就放開事務(wù)寫入請求。不過這個流控機制在真實業(yè)務(wù)場景中效果很有限，在事務(wù)寫入高峰期，可能會頻繁造成TPS抖動，但卻不能真正起到流控作用。在GreatSQL中， 針對這個缺陷進行了優(yōu)化，重新設(shè)計流控算法。增加主從延遲時間來計算流控閾值，并且同時考慮了大事務(wù)處理和主從節(jié)點的同步，流控粒度更細致，不會出現(xiàn)官方社區(qū)版本的1秒小抖動問題。

在GreatSQL中，新增選項group_replication_flow_control_replay_lag_behind用于控制MGR主從節(jié)點復(fù)制延遲閾值，當(dāng)MGR主從節(jié)點因為大事務(wù)等原因延遲超過閾值時，就會觸發(fā)流控機制。參數(shù)范圍 0 ~ ULONG_MAX，默認值600秒，可在線動態(tài)修改，且立即生效。

此外，針對不同業(yè)務(wù)場景，流控閾值設(shè)置也不盡相同。對于事務(wù)實時性要求不高的業(yè)務(wù)，可以設(shè)置較大閾值。對于內(nèi)存較大的節(jié)點，可以適當(dāng)調(diào)大閾值；反之，在內(nèi)存緊張的節(jié)點上，就要降低閾值以避免OOM風(fēng)險。

2. 小結(jié)

本節(jié)介紹了為什么MGR需要流控，已經(jīng)GreatSQL如何改進優(yōu)化流控算法。

參考資料、文檔

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

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

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

標簽：