MGR用哪一個版本？5.7 vs 8.0

前幾天有人問：「8.0的MGR與5.7相比較，有哪些不同的地方？」，在這篇文章裏，將經過增長的系統變量說明一下MySQL8.0在MGR上的變化。

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

從數量上來看，8.0比5.7多了7個變量，這7個變量對MGR產生了巨大的影響！讓咱們看一下這7個變量爲MGR帶來了哪些變化？

group_replication_autorejoin_tries：這個變量是在8.0.16版本加入的，它能夠在羣組運行時進行更改，經過這個變量能夠容許由於網絡等意外緣由脫離集羣的成員從新嘗試加入集羣。

group_replication_consistency：該變量值是在8.0.14加入的，一樣能夠在羣組運行時進行更改。該變量容許用戶經過設定不一樣的值，來保證集羣範圍內的數據一致性。該變量值能夠設置爲：

「EVENTUAL

BEFORE_ON_PRIMARY_FAILOVER

BEFORE

AFTER

BEFORE_AND_AFTER」，能夠確保在多主更新的模式下，各個組成員在徹底一致的狀態下進行更新。（5.7採用的爲最終一致性EVENTUAL）。關於這部份內容能夠參考文章——羣組複製 - 一致性讀取。

group_replication_flow_control_period：羣組複製須要依靠消息的傳播進行數據同步等一系列工做。羣組複製的設計考慮兩個工做隊列:認證隊列，二進制日誌回放隊列。每當這些隊列的大小超過用戶定義的閾值時，就會觸發調節機制。該變量定義了兩次傳播控制之間要等待的秒數，在該時長中發送傳播控制消息並運行傳播控制管理任務。

group_replication_flow_control_release_percent：羣組複製有一個節流機制，用於決定是否限制成員執行/提交新事務的速度。每一個成員都有一個基於可用容量的已肯定的寫入配額，也就是它能夠在下一階段安全發佈的大量事務。若是認證隊列或二進制日誌回放隊列大小超過用戶定義的閾值，節流機制將強制執行寫入配額。配額根據上一階段延遲的事務數量減小，而後進一步減小10%，以容許觸發問題的隊列減小其大小。該變量定義當傳播控制再也不須要限制寫入成員時應如何釋放組配額，百分比是每一個傳播控制週期的配額增長。值爲0表示一旦傳播控制閾值在限制以內，配額將在一次傳播控制中釋放。

group-replication-member-expel-timeout：指定的羣組成員在產生懷疑以後，從羣組中排除懷疑失敗的成員以前等待的時間（以秒爲單位）。

group_replication_communication_max_message_size：指定羣組間傳播消息的大小，默認值10M，超過該值後，能夠自動進行分割。該變量在8.0.16版本加入，能夠防止消息過大引發超時誤報。

group_replication_message_cache_size：羣組複製的通訊引擎會使用服務器的內存去緩存傳播的消息，該變量用於設置緩存的大小。
此外，變量group_replication_exit_state_action：是設置羣組成員離開羣組後的行爲，8.0.18爲其增長了一個OFFLINE_MODE，使用模式，不具備鏈接管理權限的用戶將沒法鏈接到該成員。

爲了提高日誌的傳輸效率，8.0增長了日誌壓縮功能，該壓縮功能既適用於傳統的主從複製，也一樣適用於MGR。

除了集羣的穩定性和性能方面，MySQL8.0裏還提供了一個克隆插件，使用該插件，能夠快速進行數據複製、部署集羣，在易用性上也進行了大幅的提高。

綜上所述，8.0的MGR經過增長變量等一系列舉措，對集羣的性能和穩定性方面進行了大幅的提高，能夠實現嚴格的集羣範圍的數據一致性，而且提供了簡單易用的克隆插件。推薦使用MGR的用戶升級至8.0版本！