本文介紹最近幾年美團(tuán)點(diǎn)評(píng)MySQL數(shù)據(jù)庫高可用架構(gòu)的演進(jìn)過程，以及我們?cè)陂_源技術(shù)基礎(chǔ)上做的一些創(chuàng)新。同時(shí)，也和業(yè)界其它方案進(jìn)行綜合對(duì)比，了解業(yè)界在高可用方面的進(jìn)展，和未來我們的一些規(guī)劃和展望。

MMM

在2015年之前，美團(tuán)點(diǎn)評(píng)(點(diǎn)評(píng)側(cè))長(zhǎng)期使用MMM(Master-Master replication manager for MySQL)做數(shù)據(jù)庫高可用，積累了比較多的經(jīng)驗(yàn)，也踩了不少坑，可以說MMM在公司數(shù)據(jù)庫高速發(fā)展過程中起到了很大的作用。

MMM的架構(gòu)如下。

如上所示，整個(gè)MySQL集群提供1個(gè)寫VIP(Virtual IP)和N(N>=1)個(gè)讀VIP提供對(duì)外服務(wù)。每個(gè)MySQL節(jié)點(diǎn)均部署有一個(gè)Agent(mmm-agent)，mmm-agent和mmm-manager保持通信狀態(tài)，定期向mmm-manager上報(bào)當(dāng)前MySQL節(jié)點(diǎn)的存活情況(這里稱之為心跳)。當(dāng)mmm-manager連續(xù)多次無法收到mmm-agent的心跳消息時(shí)，會(huì)進(jìn)行切換操作。

mmm-manager分兩種情況處理出現(xiàn)的異常。

1.出現(xiàn)異常的是從節(jié)點(diǎn)

• mmm-manager會(huì)嘗試摘掉該從節(jié)點(diǎn)的讀VIP，并將該讀VIP漂移到其它存活的節(jié)點(diǎn)上，通過這種方式實(shí)現(xiàn)從庫的高可用。

2.出現(xiàn)異常的是主節(jié)點(diǎn)

• 如果當(dāng)時(shí)節(jié)點(diǎn)還沒完全掛，只是響應(yīng)超時(shí)。則嘗試將Dead Master加上全局鎖(flush tables with read lock)。
• 在從節(jié)點(diǎn)中選擇一個(gè)候選主節(jié)點(diǎn)作為新的主節(jié)點(diǎn)，進(jìn)行數(shù)據(jù)補(bǔ)齊。
• 數(shù)據(jù)補(bǔ)齊之后，摘掉Dead Master的寫VIP，并嘗試加到新的主節(jié)點(diǎn)上。
• 將其它存活的節(jié)點(diǎn)進(jìn)行數(shù)據(jù)補(bǔ)齊，并重新掛載在新的主節(jié)點(diǎn)上。

主庫發(fā)生故障后，整個(gè)集群狀態(tài)變化如下：

mmm-manager檢測(cè)到master1發(fā)生了故障，對(duì)數(shù)據(jù)進(jìn)行補(bǔ)齊之后，將寫VIP漂移到了master2上，應(yīng)用寫操作在新的節(jié)點(diǎn)上繼續(xù)進(jìn)行。

然而，MMM架構(gòu)存在如下問題：

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

同時(shí)，MMM是Google技術(shù)團(tuán)隊(duì)開發(fā)的一款比較老的高可用產(chǎn)品，在業(yè)內(nèi)使用的并不多，社區(qū)也不活躍，Google很早就不再維護(hù)MMM的代碼分支。我們?cè)谑褂眠^程中發(fā)現(xiàn)大量Bug，部分Bug我們做了修改，并提交到開源社區(qū)，有興趣的同學(xué)可以參考這里。

MHA

針對(duì)于此，從2015年開始，美團(tuán)點(diǎn)評(píng)對(duì)MySQL高可用架構(gòu)進(jìn)行了改進(jìn)，全部更新為MHA，很大程度上解決了之前MMM遇到的各種問題。

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

整個(gè)MHA的架構(gòu)如下(為簡(jiǎn)單起見，只描述一主一從)：

這里我們對(duì)MHA做了一些優(yōu)化，避免一些腦裂問題。

比如DB服務(wù)器的上聯(lián)交換機(jī)出現(xiàn)了抖動(dòng)，導(dǎo)致主庫無法訪問，被管理節(jié)點(diǎn)判定為故障，觸發(fā)MHA切換，VIP被漂到了新主庫上。隨后交換機(jī)恢復(fù)，主庫可被訪問，但由于VIP并沒有從主庫上摘除，因此2臺(tái)機(jī)器同時(shí)擁有VIP，會(huì)產(chǎn)生腦裂。我們對(duì)MHA Manager加入了向同機(jī)架上其他物理機(jī)的探測(cè)，通過對(duì)比更多的信息來判斷是網(wǎng)絡(luò)故障還是單機(jī)故障。

MHA+Zebra (DAL)

Zebra(斑馬)是美團(tuán)點(diǎn)評(píng)基礎(chǔ)架構(gòu)團(tuán)隊(duì)開發(fā)的一個(gè)Java數(shù)據(jù)庫訪問中間件，是在c3p0基礎(chǔ)上包裝的美團(tuán)點(diǎn)評(píng)內(nèi)部使用的動(dòng)態(tài)數(shù)據(jù)源，包括讀寫分離、分庫分表、SQL流控等非常強(qiáng)的功能。它和MHA配合，成為了MySQL數(shù)據(jù)庫高可用的重要一環(huán)。如下是MHA+Zebra配合的整體架構(gòu)：

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

當(dāng)MHA切換完成之后，主動(dòng)發(fā)送消息給Zebra monitor，Zebra monitor更新ZooKeeper的配置，將主庫上配置的讀流量標(biāo)記為下線狀態(tài)。

Zebra monitor每隔一段時(shí)間(10s ~ 40s)檢測(cè)集群中節(jié)點(diǎn)的健康狀況，一旦發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)出現(xiàn)了問題，及時(shí)刷新ZooKeeper中的配置，將該節(jié)點(diǎn)標(biāo)記為下線。

一旦節(jié)點(diǎn)變更完成，客戶端監(jiān)聽到節(jié)點(diǎn)發(fā)生了變更，會(huì)立即使用新的配置重建連接，而老的連接會(huì)逐步關(guān)閉。整個(gè)集群故障切換的過程如下(僅描述Zebra monitor主動(dòng)探測(cè)的情況，***種MHA通知請(qǐng)自行腦補(bǔ)^_^)。

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

然而，這種方式中的MHA管理節(jié)點(diǎn)是單點(diǎn)，在網(wǎng)絡(luò)故障或者機(jī)器宕機(jī)情況下依然存在風(fēng)險(xiǎn)。同時(shí)，由于Master-Slave之間是基于Binlog的異步復(fù)制，也就導(dǎo)致了主庫機(jī)器宕機(jī)或者主庫無法訪問時(shí)，MHA切換過程中可能導(dǎo)致數(shù)據(jù)丟失。

另外，當(dāng)Master-Slave延遲太大時(shí)，也會(huì)給數(shù)據(jù)補(bǔ)齊這一操作帶來額外的時(shí)間開銷。

Proxy

除了Zebra中間件，美團(tuán)點(diǎn)評(píng)還有一套基于Proxy的中間件，和MHA一起配合使用。當(dāng)MHA切換后，主動(dòng)通知Proxy來進(jìn)行讀寫流量調(diào)整，Proxy相比Zebra更加靈活，同時(shí)也能覆蓋非Java應(yīng)用場(chǎng)景。缺點(diǎn)就是訪問鏈路多了一層，對(duì)應(yīng)的Response Time和故障率也有一定增加。有興趣的同學(xué)們可以自行前往GitHub查詢?cè)敿?xì)文檔詳細(xì)文檔。

未來架構(gòu)設(shè)想

上文提到的MHA架構(gòu)依然存在如下兩個(gè)問題：

• 管理節(jié)點(diǎn)單點(diǎn)。
• MySQL異步復(fù)制中的數(shù)據(jù)丟失。

針對(duì)于此，我們?cè)诓糠趾诵臉I(yè)務(wù)上使用Semi-Sync，可以保證95%以上場(chǎng)景下數(shù)據(jù)不丟失(依然存在一些極端情況下無法保障數(shù)據(jù)的強(qiáng)一致性)。另外，高可用使用分布式的Agent，在某個(gè)節(jié)點(diǎn)發(fā)生故障后，通過一定的選舉協(xié)議來選擇新的Master，從而解決了MHA Manager的單點(diǎn)問題。

針對(duì)上述問題，我們研究了業(yè)界的一些領(lǐng)先的做法，簡(jiǎn)單描述如下。

主從同步數(shù)據(jù)丟失

針對(duì)主從同步的數(shù)據(jù)丟失，一種做法是創(chuàng)建一個(gè)Binlog Server，該Server模擬Slave接受Binlog日志，主庫每次的數(shù)據(jù)寫入都需要接收到Binlog Server的ACK應(yīng)答，才認(rèn)為寫入成功。Binlog Server可以部署在就近的物理節(jié)點(diǎn)上，從而保證每次數(shù)據(jù)寫入都能快速落地到Binlog Server。在發(fā)生故障時(shí)，只需要從Binlog Server拉取數(shù)據(jù)即可保證數(shù)據(jù)不丟失。

分布式Agent高可用

針對(duì)MHA管理節(jié)點(diǎn)單點(diǎn)問題，一種做法是讓MySQL數(shù)據(jù)庫集群中每個(gè)節(jié)點(diǎn)部署Agent，發(fā)生故障時(shí)每個(gè)Agent均參與選舉投票，選舉出合適的Slave作為新的主庫，防止只通過Manager來切換，去除MHA單點(diǎn)。整個(gè)架構(gòu)如下圖所示。

MGR結(jié)合中間件高可用

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

最近幾年，MySQL社區(qū)關(guān)于分布式協(xié)議Raft和Paxos非常火，社區(qū)也推出了基于Paxos的MGR版本的MySQL，通過Paxos將一致性和切換過程下推到數(shù)據(jù)庫內(nèi)部，向上層屏蔽了切換細(xì)節(jié)。架構(gòu)如下(以MGR的single-primary為例)。

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

結(jié)語

本文介紹了美團(tuán)點(diǎn)評(píng)MySQL數(shù)據(jù)庫高可用架構(gòu)從MMM到MHA+Zebra以及MHA+Proxy的演進(jìn)歷程，同時(shí)也介紹了業(yè)界一些高可用的做法。數(shù)據(jù)庫最近幾年發(fā)展突飛猛進(jìn)，數(shù)據(jù)庫的高可用設(shè)計(jì)上沒有***的方案，只有不斷的突破和創(chuàng)新，我們也一直在這條路上探索更加優(yōu)秀的設(shè)計(jì)與更加***的方案。