本文介紹最近幾年美團點評MySQL數據庫高可用架構的演進過程，以及我們在開源技術基礎上做的一些創新。同時，也和業界其它方案進行綜合對比，了解業界在高可用方面的進展，和未來我們的一些規劃和展望。

MMM

在2015年之前，美團點評(點評側)長期使用MMM(Master-Master replication manager for MySQL)做數據庫高可用，積累了比較多的經驗，也踩了不少坑，可以說MMM在公司數據庫高速發展過程中起到了很大的作用。

MMM的架構如下。

如上所示，整個MySQL集群提供1個寫VIP(Virtual IP)和N(N>=1)個讀VIP提供對外服務。每個MySQL節點均部署有一個Agent(mmm-agent)，mmm-agent和mmm-manager保持通信狀態，定期向mmm-manager上報當前MySQL節點的存活情況(這里稱之為心跳)。當mmm-manager連續多次無法收到mmm-agent的心跳消息時，會進行切換操作。

mmm-manager分兩種情況處理出現的異常。

1.出現異常的是從節點

• mmm-manager會嘗試摘掉該從節點的讀VIP，并將該讀VIP漂移到其它存活的節點上，通過這種方式實現從庫的高可用。

2.出現異常的是主節點

• 如果當時節點還沒完全掛，只是響應超時。則嘗試將Dead Master加上全局鎖(flush tables with read lock)。
• 在從節點中選擇一個候選主節點作為新的主節點，進行數據補齊。
• 數據補齊之后，摘掉Dead Master的寫VIP，并嘗試加到新的主節點上。
• 將其它存活的節點進行數據補齊，并重新掛載在新的主節點上。

主庫發生故障后，整個集群狀態變化如下：

mmm-manager檢測到master1發生了故障，對數據進行補齊之后，將寫VIP漂移到了master2上，應用寫操作在新的節點上繼續進行。

然而，MMM架構存在如下問題：

• VIP的數量過多，管理困難(曾經有一個集群是1主6從，共計7個VIP)。某些情況下會導致集群大部分VIP同時丟失，很難分清節點上之前使用的是哪個VIP。
• mmm-agent過度敏感，容易導致VIP丟失。同時mmm-agent自身由于沒有高可用，一旦掛掉，會造成mmm-manager誤判，誤認為MySQL節點異常。
• mmm-manager存在單點，一旦由于某些原因掛掉，整個集群就失去了高可用。
• VIP需要使用ARP協議，跨網段、跨機房的高可用基本無法實現，保障能力有限。

同時，MMM是Google技術團隊開發的一款比較老的高可用產品，在業內使用的并不多，社區也不活躍，Google很早就不再維護MMM的代碼分支。我們在使用過程中發現大量Bug，部分Bug我們做了修改，并提交到開源社區，有興趣的同學可以參考這里。

MHA

針對于此，從2015年開始，美團點評對MySQL高可用架構進行了改進，全部更新為MHA，很大程度上解決了之前MMM遇到的各種問題。

MHA(MySQL Master High Availability)是由Facebook工程師Yoshinori Matsunobu開發的一款MySQL高可用軟件。從名字就可以看出，MHA只負責MySQL主庫的高可用。主庫發生故障時，MHA會選擇一個數據最接近原主庫的候選主節點(這里只有一個從節點，所以該從節點即為候選主節點)作為新的主節點，并補齊和之前Dead Master 差異的Binlog。數據補齊之后，即將寫VIP漂移到新主庫上。

整個MHA的架構如下(為簡單起見，只描述一主一從)：

這里我們對MHA做了一些優化，避免一些腦裂問題。

比如DB服務器的上聯交換機出現了抖動，導致主庫無法訪問，被管理節點判定為故障，觸發MHA切換，VIP被漂到了新主庫上。隨后交換機恢復，主庫可被訪問，但由于VIP并沒有從主庫上摘除，因此2臺機器同時擁有VIP，會產生腦裂。我們對MHA Manager加入了向同機架上其他物理機的探測，通過對比更多的信息來判斷是網絡故障還是單機故障。

MHA+Zebra (DAL)

Zebra(斑馬)是美團點評基礎架構團隊開發的一個Java數據庫訪問中間件，是在c3p0基礎上包裝的美團點評內部使用的動態數據源，包括讀寫分離、分庫分表、SQL流控等非常強的功能。它和MHA配合，成為了MySQL數據庫高可用的重要一環。如下是MHA+Zebra配合的整體架構：

還是以主庫發生故障為例，處理邏輯有如下兩種方式：

當MHA切換完成之后，主動發送消息給Zebra monitor，Zebra monitor更新ZooKeeper的配置，將主庫上配置的讀流量標記為下線狀態。

Zebra monitor每隔一段時間(10s ~ 40s)檢測集群中節點的健康狀況，一旦發現某個節點出現了問題，及時刷新ZooKeeper中的配置，將該節點標記為下線。

一旦節點變更完成，客戶端監聽到節點發生了變更，會立即使用新的配置重建連接，而老的連接會逐步關閉。整個集群故障切換的過程如下(僅描述Zebra monitor主動探測的情況，***種MHA通知請自行腦補^_^)。

由于該切換過程還是借助于VIP漂移，導致只能在同網段或者說同個二層交換機下進行，無法做到跨網段或者跨機房的高可用。為解決這個問題，我們對MHA進行了二次開發，將MHA添加VIP的操作去掉，切換完之后通知Zebra monitor去重新調整節點的讀寫信息(將Wirte調整為new master的實IP，將Dead Master的讀流量摘除)，整個切換就完全去VIP化，做到跨網段、甚至跨機房切換，徹底解決之前高可用僅局限于同網段的問題。上述切換過程就變成了如下圖。

然而，這種方式中的MHA管理節點是單點，在網絡故障或者機器宕機情況下依然存在風險。同時，由于Master-Slave之間是基于Binlog的異步復制，也就導致了主庫機器宕機或者主庫無法訪問時，MHA切換過程中可能導致數據丟失。

另外，當Master-Slave延遲太大時，也會給數據補齊這一操作帶來額外的時間開銷。

Proxy

除了Zebra中間件，美團點評還有一套基于Proxy的中間件，和MHA一起配合使用。當MHA切換后，主動通知Proxy來進行讀寫流量調整，Proxy相比Zebra更加靈活，同時也能覆蓋非Java應用場景。缺點就是訪問鏈路多了一層，對應的Response Time和故障率也有一定增加。有興趣的同學們可以自行前往GitHub查詢詳細文檔詳細文檔。

未來架構設想

上文提到的MHA架構依然存在如下兩個問題：

• 管理節點單點。
• MySQL異步復制中的數據丟失。

針對于此，我們在部分核心業務上使用Semi-Sync，可以保證95%以上場景下數據不丟失(依然存在一些極端情況下無法保障數據的強一致性)。另外，高可用使用分布式的Agent，在某個節點發生故障后，通過一定的選舉協議來選擇新的Master，從而解決了MHA Manager的單點問題。

針對上述問題，我們研究了業界的一些領先的做法，簡單描述如下。

主從同步數據丟失

針對主從同步的數據丟失，一種做法是創建一個Binlog Server，該Server模擬Slave接受Binlog日志，主庫每次的數據寫入都需要接收到Binlog Server的ACK應答，才認為寫入成功。Binlog Server可以部署在就近的物理節點上，從而保證每次數據寫入都能快速落地到Binlog Server。在發生故障時，只需要從Binlog Server拉取數據即可保證數據不丟失。

分布式Agent高可用

針對MHA管理節點單點問題，一種做法是讓MySQL數據庫集群中每個節點部署Agent，發生故障時每個Agent均參與選舉投票，選舉出合適的Slave作為新的主庫，防止只通過Manager來切換，去除MHA單點。整個架構如下圖所示。

MGR結合中間件高可用

上述方式某種程度上解決了之前的問題，但是Agent和Binlog Server卻是新引入的風險，同時Binlog Server的存在，也帶來了響應時間上的額外開銷。有沒有一種方式，能夠去除Binlog Server和Agent，又能保證數據不丟失呢 ?答案當然是有的。

最近幾年，MySQL社區關于分布式協議Raft和Paxos非常火，社區也推出了基于Paxos的MGR版本的MySQL，通過Paxos將一致性和切換過程下推到數據庫內部，向上層屏蔽了切換細節。架構如下(以MGR的single-primary為例)。

當數據庫發生故障時，MySQL內部自己進行切換。切換完成后將topo結構推送給Zebra-monitor，Zebra-monitor進行相應的讀寫流量變更。不過，該架構存在與Binlog Server同樣的需要回復確認問題，就是每次主庫數據寫入，都需要大多數節點回復ACK，該次寫入才算成功，存在一定的響應時間開銷。同時，每個MGR集群必須需要奇數個數(大于1)的節點，導致原先只需要一主一從兩臺機器，現在需要至少三臺，帶來一定的資源浪費。但不管怎么說，MGR的出現是無疑是MySQL數據庫又一次偉大的創新。

結語

本文介紹了美團點評MySQL數據庫高可用架構從MMM到MHA+Zebra以及MHA+Proxy的演進歷程，同時也介紹了業界一些高可用的做法。數據庫最近幾年發展突飛猛進，數據庫的高可用設計上沒有***的方案，只有不斷的突破和創新，我們也一直在這條路上探索更加優秀的設計與更加***的方案。