社區投稿 | MySQL MGR"一致性讀寫"特性解讀

原創做者： 田帥萌

---

MySQL 8.0.14版本增長了一個新特性：MGR讀寫一致性；有了此特性，「媽媽」不再用擔憂讀MGR非寫節點數據會產生不一致啦。

有同窗會疑問：「MGR不是'全同步'麼，也會產生讀寫不一致？」，在此確定的告訴你們MGR會產生讀寫不一致，緣由以下：

MGR相對於半同步複製，在relay log前增長了衝突檢查協調，可是binlog回放仍然可能延時，也就是跟咱們熟悉的半同步複製存在io線程的回放延遲狀況相似。固然關於IO線程回放慢的緣由，跟半同步也相似，好比大事務！！

因此MGR並非全同步方案，關於如何處理一致性讀寫的問題，MySQL 在8.0.14版本中加入了「讀寫一致性」特性，並引入了參數：**group_replication_consistenc，**下面將對讀寫一致性的相關參數及不一樣應用場景進行詳細說明。

 

參數group_replication_consistenc的說明

可選配置值

• EVENTUAL 默認值，開啓該級別的事務（T2），事務執行前不會等待先序事務（T1）的回放完成，也不會影響後序事務等待該事務回放完成。

• **BEFORE **開啓了該級別的事務（T2），在開始前首先要等待先序事務（T1）的回放完成，確保此事務將在最新的數據上執行。

• **AFTER，**開啓該級別的事務（T1），只有等該事務回放完成。其餘後序事務（T2）纔開始執行，這樣全部後序事務都會讀取包含其更改的數據庫狀態，而無論它們在哪一個成員上執行。

• **BEFORE_AND_AFTER **開啓該級別等事務（T2），須要等待前序事務的回放完成（T1）；同時後序事務（T3）等待該事務的回放完成；

• **BEFORE_ON_PRIMARY_FAILOVER，**在發生切換時，連到新主的事務會被阻塞，等待先序提交的事務回放完成；這樣確保在故障切換時客戶端都能讀取到主服務器上的最新數據，保證了一致性

group_replication_consistency 參數能夠用法SESSION，GLOBAL去進行更改。

官方說明請參考：

https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html

 

MGR讀寫一致性的優缺點

官方引入的MGR讀寫一致性既有它自身的自然優點，也不可避免的存在相應的不足，其優缺點以下：

• 優勢：MGR配合中間件，好比DBLE這類有讀寫分離功能的中間件，在MGR單主模式下，能夠根據業務場景進行讀寫分離，不用擔憂會產生延遲，充分利用了MGR主節點之外的節點。

• 缺點：使用讀寫一致性會對性能有極大影響，尤爲是網絡環境不穩定的場景下。

在實際應用中須要你們因地制宜，根據實際狀況選擇最適配的方案。

 

MGR讀寫一致性的方案

針對不一樣應用場景應當如何選擇MGR讀寫一致性的相關方式，官方提供了幾個參數以及與其相對應的應用場景：

AFTER

適用場景1：寫少讀多的場景進行讀寫分離，擔憂讀取到過時事務，可選擇AFTER。

適用場景2：只讀爲主的集羣，有RW的事務須要保證提交的事務能被其餘後序事務讀到最新讀數據，可選擇AFTER。

BEFORE

適用場景1：應用大量寫入數據，偶爾進行讀取一致性數據，應當選擇BEFORE。

適用場景2：有特定事務須要讀寫一致性，以便對敏感數據操做時，始終讀取最新的數據；應當選擇BEFORE。

BEFORE_AND_AFTER

適用場景：有一個讀爲主的集羣，有RW的事務既要保證讀到最新的數據，又要保證這個事務提交後，被其餘後序事務讀到；在這種狀況下可選擇BEFORE_AND_AFTER。

在特定會話上設置一致性

舉例1：某一事務語句，須要其餘節點的數據強一致性。可使用SET@@SESSION.group_replication_consistency= ‘AFTER’進行設置。

舉例2：跟例1類似，在天天執行分析語句事務而且須要得到讀取新數據的狀況下。

可使用SET @@SESSION.group_replication_consistency= ‘BEFORE’ 進行設置

參考文檔：

https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-consistency-guarantees.html#group-replication-choose-consistency-level