在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉

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

1. MGR流控

(資料圖)

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

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

MGR流控有幾個要點：

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

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

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

當設置流控配額百分比（group_replication_flow_control_member_quota_percent）時，會在多個啟用流控的Primary節點間平攤配額。

流控只針對寫事務，不影響只讀事務。

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

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

此外，針對不同業務場景，流控閾值設置也不盡相同。對于事務實時性要求不高的業務，可以設置較大閾值。對于內存較大的節點，可以適當調大閾值；反之，在內存緊張的節點上，就要降低閾值以避免OOM風險。

本節介紹了為什么MGR需要流控，已經GreatSQL如何改進優化流控算法。

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

數據庫內核開發 - 溫正湖(https://www.zhihu.com/column/c_206071340)

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

關鍵詞： 流量控制 事務處理 不盡相同 也很容易