MYSQL 8的Group replication和5.X有什么改進

小編給大家分享一下MYSQL 8的Group replication和5.X有什么改進，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

MYSQL 8 Group Replication 最近開始做實驗了，MYSQL 5.7的MGR 在使用了不到一年的時間里面，發現了不少問題，也解決了不少問題。MYSQL 8 GROUP REPLICATION 在搭建環境中發現的第一個感覺就是比MYSQL 5.7 在節點進入集群的速度上要快了。

沒有對比就沒有傷害，下面就來對比一下MYSQL 8 的Group replication 和5.X 有什么改進。

performance_schema.replicatiton_group_members 展示的信息不同了

熟悉MYSQL 5.7X的MGR的同學在查詢集群中的節點的狀態通常使用上面的VIEW，但是MYSQL 5.7x 中展示的信息只有 

CHANNEL_NAME

MEMBER_ID

MEMBER_HOST

MEMBER_PORT

MEMBER_STATE

這里面其實缺失一項最重要的展示，就是那個機器是主呀？當然你可以部署多主的，但在實際應用中，這么干的終究是少數，同時也都是不重要的系統，而在使用的方式上也有差。

MYSQL 8.0 直接彌補了這個問題，下圖中可以看到，比MYSQL 5.7X多了兩列，一列是那個是主，另一列是版本。

有人問，顯示版本有什么用，當然有用，我是不是可以不同的版本進行MGR的連接，不同的版本我在查看狀態的時候，是不是就帶出來版本號讓我一目了然。

當然這僅僅是一個開始，在MYSQL 5.7時被吐槽最多的MGR中缺少的功能就是，不能選擇哪個是主，雖然后期可以通過權重的方式來搞，但還是不方便。現在MYSQL MGR 可以直接的進行自主選主的工作。通過下圖，可以很清楚的看到，如何手工進行自動選主的工作以及切換。

SELECT group_replication_set_as_primary('3dca6cf9-8a66-11e9-bd97-000c29ba69f2');

并且MYSQL 8.0還添加了一些新的參數和功能來完善MGR 的應用性，例如

group_replication_exit_state_action

之前的版本一直在成員由于各種原因和集群失聯后的處理工作，并且不能被選中，現在這個問題可以選中了

通過上面的參數，你可以選擇是關機還是設置成read_only

當然被吐槽的還有一個關鍵點，就是由于網絡的問題，造成的誤踢出的節點，在 5.7 中沒有調試這樣的參數，而現在在MYSQL 8 有了

group_replication_member_expel_timeout

通過這個參數，你可以很輕松的避開某些由于網絡問題，或突發的網絡流量引起的不必要的，節點踢出問題。

同時分布式數據庫中的信息交互成本也應該被考慮，因為要有回滾的問題，這是不能回避的問題。所以MYSQL 8.0 可以調整這樣的參數

group_replication_transaction_size_limit

默認8.0設置為 143MB，的事務控制，在MYSQL5.7是沒有設置的，默認是不限制。所以經常不大會用MYSQL ，那MYSQL當ORACLE 用的親們，可能你在操作大事務的情況下，會被踢回去，這不怪MYSQL，怪你沒有真正領會MYSQL使用的精髓。

說完這些，還的說說某些參數已經不再8.0支持了

如果在MYSQL 5.7X上，在進行從庫的加入時，經常會用到這個命令，來講GTID不一致的情況下的從庫加入到集群中，（當然你首先的保證數據的三個節點應該是一致的情形下，采用這個方法）

group_replication_allow_local_disjoint_gtids_join

   其實在監控方面可以說的地方還很多，不過今天就到這里，休息休息一下

以上是“MYSQL 8的Group replication和5.X有什么改進”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！