MySQL爲什麼如此流行的原因是因爲它很早就有了非常成熟的高可用方案，這個方案就是mha，很多互聯網公司都是基於mha做的高可用，所有受衆面非常廣。其實還有個小原因就是我們從上大學學習數據庫原理這門課的時候老師就是拿mysql數據庫作爲例子，使得我們大部分人對更加熟悉。
相比起來pg的流複製出來的較晚，而且高可用方案也不統一，雖然流複製是基於xlog物理日誌的複製技術，性能比mysql binlog邏輯複製好很多，但是相比起來pg差在生態上，在中國pg的客羣並不大，受衆面沒那麼廣。
好，進入正題，mysql的mha和mgr到底誰纔是“正房”。誰纔是生產環境中最好的高可用方案。
這麼比較其實是有點問題的。我們知道mha是外部的基於mysql主從半同步開發的一套高可用切換方案，它並不屬於mysql內核，獨立於mysql存在於外圍，mha重點在切換，可以理解爲一套切換工具。而mgr存在於mysql內核層面，是內核層面數據強一致方案，它的重點在高可用強一致，如果將mgr用在生產環境中，那麼針對mgr，還需要開發一套監控及切換方案，而mha將這一整套切換方案vip之類的都考慮進去了。
mha會在集羣中某臺機器一般是slave節點安裝mha manager，當master出現故障時，可以自動將最新數據的slave提升爲master同時將所有其他的slave指向新的master，整個過程是透明的，對應用無感知，切換時間一般在30s以內，非常高效。mha適用於一主一從，一主多從，一般配合半同步使用，預防數據丟失。
mha大致原理是manager進程會定期（一般是1s一次）探測主庫節點，當主庫出現故障時，mha會找到應用了最新日誌的slave的binlog位置，並且拉取主庫和最新從庫的差異日誌並應用到該從庫上。，然後將該從庫提升爲master，並且將其他從庫指向新主庫，切換過程配合vip的漂移。
mgr全稱是mysql group replication，它其實是對mysql半同步的一個創新，它至少要求三個節點，三個節點間基於paxos協議做同步，paxos協議是多主節點的強一致協議。
mgr有兩種模式，單主模式和多主模式，區別就是是否提供多個節點同時寫入的能力。由於mgr採用樂觀鎖，在高併發的情況下很容易在提交那一刻造成衝突，所以在生產環境中一般採用單主模式居多。
Paxos協議能容忍少數節點宕機，因爲paxos協議要求一半以上的節點收到日誌主庫纔可以提交。在單主模式下，當主庫宕機，集羣會根據group_replication_member_weight設置的權重值進行備機升主，因爲是強一致協議，所以不存在日誌是否是最新的問題，如果權重相同，那麼會根據server的uuid進行排序。
mgr本身還有一些限制，比如寫集合衝突問題，必須要求有主鍵，只支持innodb，不支持外鍵、save point等，還有集羣的強一致導致對網絡的要求較高，如果遇到網絡波動，對集羣的影響較大。
mgr本身能夠實現故障自動選舉，但是生產環境需要做到對應用的透明，所以一般是基於vip的，應用連接的是vip，如果發生切換，需要將vip也漂移到新主庫，這裏其實還涉及到很多判斷和切換邏輯，所以mgr並不是切換方案，他只是提供了一種新的強一致高可用技術，要想把它用於生產環境中其實還有很多工具和腳本要進行開發。
個人覺得，mha在mysql的高可用方面還是最經典成熟和無可撼動的。至於mgr新技術大家也可以抱着研究的心態玩一玩，但是說用mgr來替換mha不管從成本還是可靠性考慮我覺得都不可取，僅代表個人觀點哈。
好吧，加油吧。
歡迎關注我的公衆號：數據庫架構之美
