如何看待MySQL發布的Group Replication？

01-07

MySQL Group Replication（下簡稱MGR）準確來說是官方推出的高可用解決方案，基於原生複製技術，並以插件的方式提供。其包含下面的特性：

複製的管理操作變得更為自動化，還在Backup + CHANGE MASTER建複製你就out了；
通過Paxos協議提供資料庫集群節點數據強一致保證，掃清了MySQL進入金融行業最後的障礙。打臉了淘寶陽振坤老師對於MySQL無法支持強一致的論調；
集群間所有節點可寫入，這是很多同學夢寐以求的功能，解決了單個集群的寫入性能，所有節點都能讀寫，不過現實還是有些殘酷；
解決網路分區導致的腦裂問題，提升複製數據的可靠性。

有小夥伴也把MGR稱為MySQL版的RAC。當然，這兩者架構上還是有很大的差別，MGR是Share Nothing，Oracle RAC是Share Everything。

熟悉Galera的同學肯定會說，MGR和Gelera非常相像。而已有一部分不怕死的公司在生產環境嘗試用Galera高可用解決方案，甚至是在某些銀行。但他們遇到的問題卻相當嚴重，相信真正在生產環境中使用過Galera的同學必定會同意我的觀點。

相比Galera，MGR的優點在於：

MySQL官方出品，品控有保障，後續技術有支持；
MGR使用的Paxos協議，性能更好，即使MGR集群節點數再多，性能也能平穩。解決了Gelera實際只能用三個節點，網路抖動造成的性能和穩定性問題；
支持多個操作系統平台，而Galera僅支持Linux系統

先看多個主節點（multi-master）下，MGR的性能提升，即多個節點同時讀寫測試[1]：

當參數flow-control-mode設置為disable時，即允許集群節點間存在延遲，這時隨著節點數的不斷增加，MGR集群的性能可有明顯地提升。若為保障讀一致性，則MGR集群性能在5個節點時，幾乎於單MySQL實例性能相當。

小夥伴們最關心的MGR vs Galera[2]：

無需多言，上面的測試結果基本宣告了Galera的死亡。曾經，Galera是款偉大而又引領時代的產品，死於2016年12月12日。PS：這是我個人的預測，有人說太武斷，那麼大家留個爪，幾年後再回頭來看。特別是抱著PXC不放的人，實在想不出什麼正常的理由。就好像官方已經提供了原生複製機制，你偏要用Tungsten做主從同步。

MGR的限制

僅支持InnoDB表，並且每張表一定要有一個主鍵，用於做write set的衝突檢測；
必須打開GTID特性，二進位日誌格式必須設置為ROW，用於選主與write set
COMMIT可能會導致失敗，類似於快照事務隔離級別的失敗場景
目前一個MGR集群最多支持9個節點
不支持外鍵於save point特性，無法做全局間的約束檢測與部分部分回滾
二進位日誌不支持binlog event checksum

在區區看來，MGR只是Oracle官方野心的第一步，更期待未來InnoDB Cluster[3]的GA。從目前的發展路線圖看，未來官方會將其打造成一個分散式的文檔資料庫集群，對手當然是更為強大更為商業更偉大的公司——MongoDB。但是，一個支持事務，支持行級鎖與MVCC，支持數據強一致保障，基於互聯網最流行與穩定的MySQL的分散式文檔資料庫，有誰能拒絕這樣的誘惑？

參考文獻

Zooming-in on Group Replication performance
Performance Evaluation: MySQL 5.7 Group Replication (GA Release)
MySQL InnoDB Cluster Userguide

粗略看了一下目前master代碼裡面的xcom組件代碼，是標準的paxos實現，標準的RSM模式。失望是對這個實現沒有看到太多亮點，但最大的亮點就是標準，能嚴格保證正確性。

唯一的不同點是對於paxos的instance，不同節點規定了自己能進行propose的instanceid，比如三個節點的集群，節點1隻能propose instance 0，3，6...節點2就是1，4，6...，對於非自己能propose的節點，如果遲遲沒propose，則只能由其他節點進行nullvalue的填充。狀態機應該還是一個單線程串列執行。這個其實也就是在極低延遲的網路下能稍微解決一下活鎖問題。

所以，多節點應該只是宣傳賣點。總所周知，paxos本身無租約的概念，租約只不過是paxos上層的狀態機。所以：

只要你用了paxos，肯定可以支持多點寫入。

只要你用了paxos，你應該會建議單點寫入。

目前默認的配置就是single-master模式。

另外看官方的測試非同步複製和同步複製的性能差距不是很大，說明測試環境可能所有節點都在一個機房上面，這種環境下多點寫入的性能不會急劇下降，也期待官方放出更多網路環境下的測試報告。

和當年MySQL支持事務功能一樣，是個大新聞。

但和當年對比，圈子更熱鬧了,吃瓜群眾也更多，當年MySQL支持事務的時候，恕我孤陋寡聞，當年貌似不像現在這樣，國內的大公司有自己的實現方案並開源，如騰訊前不久開源的PhxSQL和阿里的OceanBase。

Oracle有強大的資金來確保MySQL官方做這樣的事情，也有生態的先發優勢，國內很多企業可能會更容易接受MySQL的這個方案，但開源產品在大公司的業務場景裡面，也不一定是最優的。

請參考Facebook自己造的一個輪子 MyRocks存儲引擎，給FB省了不少MySQL伺服器。

阿里也有足夠的資源去做MySQL內核補丁的研發和開源，也提交了不少到官方。

可能現在缺的是一個存儲引擎級別的開源方案，能被官方接受，能被社區廣泛採用。

OceanBase，阿里巴巴/螞蟻金服自研的分散式無共享關係資料庫，2013年就實現了Paxos協議，正是憑藉著Paxos協議少數派節點故障不丟失數據、不停止服務的特點以及OceanBase的高性能，OceanBase在2014年替換了支付寶交易系統中的Oracle及其共享存儲，2015年替換了支付寶的支付系統中的Oracle及其共享存儲，2016年更是替換了支付寶最最核心的賬務系統中的Oracle及其共享存儲，極大地降低了成本，終於即將完成螞蟻金服的全面去O。3年後的今天，MySQL也實現了Paxos協議，是否有人了解，咱們中國的工程師在這其中貢獻是什麼？

說明 MySQL 官方認為 master-slave 複製不是未來，Paxos/Raft 這種才是

對mysql自身來講不錯，是一大進步。不過從整個行業來看，動作有點慢了。

轉載自己的另一個問題下的回答。

即使你用了mysql replication group（首先需要穩定下來），還是需要自己分庫分表，自己讀寫分離，自己分散式事務，自己負載均衡。。。它不解決擴展性問題。

MySQL 三節點企業版:https://help.aliyun.com/document_detail/51701.htm?spm=5176.7920929.603378.1.hUuItV

其實阿里也已經通過Paxos協議來實現集群節點的強一致性了，當然這種實現對Oracle MS這種公司來說根本不是難事，只是一旦實現了就革自己命了，自己賺錢的產品賣不出去了。氣哭

一直看好mysql開源的產品，趕緊完善，力求少些套路，多一些使用，並且真正實現高可用，而不是用了就是坑，坑不完的坑....

GR官方文檔技術細節比較粗略。關於 paxos, 說實話我很難相信真正無主的實現性能可以超過租約，幾乎不受節點數目增加影響。真正的無主多 master paxos 實現(劃分多個group ，導致每個 group 主分散在多節點不算)如何優化掉顯式prepare 消息，如何解決活鎖是個大問題。非常好奇 GR 的實現細節。

同時很好奇 GR拿 paxos 具體保證什麼性質，是否和文檔中的全局事物序號有關。

就官文描述的來看，它貌似和很多已知 paxos 實現都有差異，就清晰的一點，當一個節點被失敗偵測機制判定掛了，它的處理是發起一次 view change 將它從 group 中移除，和一個節點退出處理一致，好處是支持 group 降級。5個節點的集群掛兩個後，降級了還能再掛一個。壞處是節點可能只是只是被網路隔離還有救但已被火葬。當然這不是重點，重點是跪求大神解惑前兩個給指條明路！

剛和Oracle做過一次交流，最多支持9個節點，官方建議single write , 個人感覺mysql innodb cluser才是終極目標。

paxos/raft越來越多的進入公眾視野，這是好事

趕緊完善，正好下個財年換架構