《云數(shù)據(jù)庫(kù)高可用解決方案技術(shù)解析》要點(diǎn)：
本文介紹了云數(shù)據(jù)庫(kù)高可用解決方案技術(shù)解析，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

高可用英文翻譯為”High Availability”,從字面上理解就是要做到服務(wù)的full-time的持續(xù)可用,但老實(shí)說(shuō),要做到full-time是不現(xiàn)實(shí)的,因?yàn)槟軌蛴绊懴到y(tǒng)服務(wù)可用性的因素實(shí)在是太多了,除了軟件BUG、硬件故障外還包括系統(tǒng)所依賴的一些第三方服務(wù)(如運(yùn)營(yíng)商提供的帶寬),甚至還包括天災(zāi)人禍等；因此我理解所謂的高可用意味著”更少的停服時(shí)間”,而工業(yè)界也有一套測(cè)量系統(tǒng)可用性的標(biāo)準(zhǔn),即大家所熟知的SLA(Service Level Agrement),也就是幾個(gè)9的可用性(如下表)：

在工業(yè)應(yīng)用場(chǎng)景中,如當(dāng)下做在線服務(wù)的各大互聯(lián)網(wǎng)公司,號(hào)稱7*24小時(shí)的不間斷服務(wù),想想如果只是達(dá)到一個(gè)9的可用性將會(huì)是一種什么樣的災(zāi)難；而要做到5個(gè)9的可用性就意味著全年只有一次服務(wù)宕機(jī),而且得在5分鐘左右就恢復(fù),其中的難度也是不言而喻的,我想只是采用技術(shù)手段不足以做到,還需要通過(guò)一整套完備嚴(yán)謹(jǐn)?shù)墓こ坦芾矸婪都芭涮坠ぞ摺?yōu)秀工程運(yùn)維人員等.

云計(jì)算號(hào)稱互聯(lián)網(wǎng)公司的水和電,高可用猶如云服務(wù)商的生命線,而云數(shù)據(jù)庫(kù)作為該領(lǐng)域的一項(xiàng)重要服務(wù)更是接受著不同維度的考驗(yàn),因?yàn)樵贫顺汕先f(wàn)個(gè)用戶數(shù)據(jù)庫(kù)實(shí)例所面臨的問(wèn)題會(huì)更加五花八門(mén)；下面將先介紹Mysql領(lǐng)域幾個(gè)典型的高可用解決方案,分析其中的關(guān)鍵技術(shù)及適用場(chǎng)景,并在此基礎(chǔ)上介紹和分享UDB的高可用方案.

1.高可用數(shù)據(jù)庫(kù)關(guān)鍵技術(shù)點(diǎn)

數(shù)據(jù)庫(kù)服務(wù)和很多工業(yè)服務(wù)在高可用技術(shù)方案是相通的,為了實(shí)現(xiàn)高可用首先實(shí)現(xiàn)服務(wù)的”冗余”,即服務(wù)的集群化,如果服務(wù)有冗余備份,宕機(jī)后還有其它備份服務(wù)(熱備和冷備)可以頂上,所以實(shí)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)的”冗余”也是高可用數(shù)據(jù)庫(kù)的核心準(zhǔn)則；而有了”冗余”備份后還不夠,如果每次宕機(jī)都需要人工恢復(fù)切換至備份服務(wù),恢復(fù)時(shí)間得不到保證,同時(shí)人為的故障恢復(fù)過(guò)程中可能會(huì)引入新的風(fēng)險(xiǎn)(人為事故),從而降低了服務(wù)的可用性,因此必須還具備”自動(dòng)故障轉(zhuǎn)移”功能.而數(shù)據(jù)庫(kù)服務(wù)相比于其它系統(tǒng)的高可用,在以上兩個(gè)關(guān)鍵技術(shù)點(diǎn)的實(shí)現(xiàn)上會(huì)更加的困難,因?yàn)閭鹘y(tǒng)RDMS對(duì)數(shù)據(jù)和事務(wù)的持久性和穩(wěn)定性是要求非高的,從也提高了對(duì)冗余數(shù)據(jù)的一致性的要求和實(shí)現(xiàn)難度.

2.高可用Mysql典型解決方案

下圖是Oracle官方對(duì)Mysql幾種典型高可用方案及可用性的總結(jié),由于時(shí)間相對(duì)較早并且隨著近幾年分布式一致性協(xié)議在工業(yè)界的實(shí)踐和發(fā)展,Mysql高可用方案又有了全新的發(fā)展方向以及相對(duì)成熟的方案,下面將一并羅列和解析.

(1)Mysql Replication 就是通過(guò)Mysql原生的復(fù)制技術(shù)來(lái)實(shí)現(xiàn)數(shù)據(jù)的冗余,該方案也是最易實(shí)現(xiàn)和通用的方案,相關(guān)的原理介紹網(wǎng)上介紹很多,這里不再詳細(xì)贅述,實(shí)現(xiàn)原理主要是通過(guò)2PC來(lái)實(shí)現(xiàn)本地BINLOG和本地?cái)?shù)據(jù)的一致性,并再此基礎(chǔ)上通過(guò)兩個(gè)線程(IO線程和SQL線程)來(lái)實(shí)現(xiàn)遠(yuǎn)端數(shù)據(jù)和本地?cái)?shù)據(jù)的同步,根據(jù)數(shù)據(jù)一致性程度不同復(fù)制技術(shù)又可以分為異步復(fù)制、半同步復(fù)制以及同步復(fù)制,另外在此冗余技術(shù)之上,一般會(huì)搭配使用MysqlProxy、keepalived、MHA等第三方軟件來(lái)實(shí)現(xiàn)自動(dòng)容災(zāi),此技術(shù)方案如果不做一定優(yōu)化,可用性一般不到2個(gè)9.

(2)Mysql Fabric 是Oracle官方提供的一種Mysql高可用方案,通過(guò)數(shù)據(jù)分片下的讀寫(xiě)分離模式,該方案的可用性達(dá)到2個(gè)9.

(3)DRBD磁盤(pán)復(fù)制,分布式塊設(shè)備復(fù)制(Distributed Relicated Block Deivce,DRBD),是一種基于軟件、基于網(wǎng)絡(luò)的塊復(fù)制存儲(chǔ)解決方案,主要用于對(duì)服務(wù)器之間的磁盤(pán)、分區(qū)、邏輯卷等進(jìn)行數(shù)據(jù)鏡像,當(dāng)用戶將數(shù)據(jù)寫(xiě)入本地磁盤(pán)時(shí),還會(huì)將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺(tái)主機(jī)的磁盤(pán)上,這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)就可以保證實(shí)時(shí)同步,當(dāng)本地主機(jī)出現(xiàn)問(wèn)題,遠(yuǎn)程主機(jī)上還保留著一份相同的數(shù)據(jù),可以繼續(xù)使用,保證了數(shù)據(jù)的安全,該方案缺點(diǎn)是IO性能影響嚴(yán)重,可用性不到3個(gè)9.

(4)Solaris Clustering,該方案代表這另一種技術(shù)方向,即以共享存儲(chǔ)為基礎(chǔ),實(shí)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)器和存儲(chǔ)設(shè)備的解耦,這樣數(shù)據(jù)庫(kù)服務(wù)器之間的冗余與數(shù)據(jù)無(wú)關(guān),而數(shù)據(jù)的冗余則通過(guò)SAN共享儲(chǔ)存或者分布式存儲(chǔ)系統(tǒng)來(lái)實(shí)現(xiàn),當(dāng)然Solaris Clustering除此之外還提供了操作系統(tǒng)、硬件等各個(gè)層面的監(jiān)控機(jī)制,該方案的可用性達(dá)到接近4個(gè)9,但是實(shí)現(xiàn)代價(jià)大,價(jià)格昂貴.

(5)Mysql Cluster是官方提供的一個(gè)開(kāi)源方案,其將Mysql的集群分為SQL節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn),數(shù)據(jù)節(jié)點(diǎn)通過(guò)一種內(nèi)存中的存儲(chǔ)引擎來(lái)實(shí)現(xiàn)自動(dòng)sharding和復(fù)制,雖然該方案號(hào)稱接近5個(gè)9的可用性,但是缺點(diǎn)也是很多,如對(duì)內(nèi)存消耗大,使用成本高,犧牲了過(guò)多的SQL語(yǔ)言特性,配置復(fù)雜等.

(6)基于PAXOS分布式一致性協(xié)議的方案,Paxos 協(xié)議主要多數(shù)派投票的方式,來(lái)就分布式系統(tǒng)中某個(gè)值達(dá)成一致,該算法被業(yè)界認(rèn)為唯一的分布式一致性算法,包括其在內(nèi)衍生出來(lái)的分布式一致性算法(如Raft等)也在很多肯多開(kāi)源分布式系統(tǒng)得到應(yīng)用.Paxos與MySQL相結(jié)合可以實(shí)現(xiàn)在分布式的MySQL數(shù)據(jù)庫(kù)最終一致性從而保證高可用,而使用分布式算法用來(lái)解決MySQL數(shù)據(jù)庫(kù)數(shù)據(jù)一致性的問(wèn)題的方法,也越來(lái)越被人們所接受,一系列產(chǎn)品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來(lái)越多的被應(yīng)用到生產(chǎn)環(huán)境,而最近Oracle官方所推出的MySQL Group Replication的GA,更使其在Mysql高可用領(lǐng)域成為了一種民用技術(shù)；因此使用分布式協(xié)議和多副本來(lái)解決數(shù)據(jù)庫(kù)一致性問(wèn)題已經(jīng)成為了主流的方向.但是此類方案還出于初級(jí)階段,不夠成熟,同時(shí)分布式一致性協(xié)議由于網(wǎng)絡(luò)開(kāi)銷的原因在性能上還有待提高和優(yōu)化.

3.高可用數(shù)據(jù)庫(kù)案例分享–UDB

為了實(shí)現(xiàn)云數(shù)據(jù)庫(kù)服務(wù)的高可用,UDB基于半同步復(fù)制技術(shù)采用雙主的熱備架構(gòu),為了實(shí)現(xiàn)故障自動(dòng)轉(zhuǎn)移,并在此基礎(chǔ)上實(shí)現(xiàn)了Proxy模塊,該模塊不僅負(fù)責(zé)數(shù)據(jù)業(yè)務(wù)的轉(zhuǎn)發(fā),同時(shí)還監(jiān)控后端DB的健康狀況,雙主數(shù)據(jù)一致性檢測(cè),并在后端DB宕機(jī)情況下,在不影響數(shù)據(jù)一致性的情況下,完成數(shù)據(jù)業(yè)務(wù)切換,整個(gè)架構(gòu)及容災(zāi)過(guò)程如下圖：

UDB宕機(jī)容災(zāi)

也許從架構(gòu)上看很簡(jiǎn)單,一主一備的架構(gòu)沒(méi)有什么新意,但是深入到細(xì)節(jié)中會(huì)發(fā)現(xiàn)有很多問(wèn)題和難點(diǎn),或者說(shuō)這些問(wèn)題都圍繞這一個(gè)目標(biāo),如何保證數(shù)據(jù)一致性.

普通的異步復(fù)制對(duì)數(shù)據(jù)庫(kù)性能影響小,但是主從數(shù)據(jù)一致性難以保證；強(qiáng)同步復(fù)制雖然保證了主從強(qiáng)一致,但是可用性很差；因此udb選擇了折中的方案即半同步復(fù)制,但只是簡(jiǎn)單的使用半同步復(fù)制還是不夠,通過(guò)分析半同步復(fù)制的過(guò)程和原理,會(huì)發(fā)現(xiàn)半同步復(fù)制會(huì)存在以下一些缺陷,下面將分析缺陷的同時(shí)介紹下udb的解決方案和策略：

1、臨界事務(wù)問(wèn)題?

什么是臨界事務(wù),臨界事務(wù)就是在宕機(jī)那個(gè)時(shí)間點(diǎn)主庫(kù)正在提交的事務(wù),這個(gè)事務(wù)可能已經(jīng)提交,可能已經(jīng)fsync到磁盤(pán),但是確沒(méi)有同步到從庫(kù)中去,半同步復(fù)制對(duì)于臨界事務(wù)是沒(méi)法保證的,如下圖是myql5.7無(wú)損復(fù)制一次事務(wù)commit流程(udb基于次復(fù)制技術(shù)做了優(yōu)化)：

如上圖,我們對(duì)5.7版本中的無(wú)損復(fù)制模式(默認(rèn)模式下)的半同步復(fù)制的主機(jī)commit做了細(xì)分,拆成7個(gè)可能crash的階段,考慮到雙機(jī)切換后可能會(huì)導(dǎo)致的數(shù)據(jù)丟失和數(shù)據(jù)一致性異常,我們對(duì)每個(gè)階段有如下分析：

• 在階段1,2,3發(fā)生了crash,由于主庫(kù)重啟后事務(wù)會(huì)回滾,binlog未發(fā)送到從庫(kù),所以不會(huì)發(fā)生異常.
• 在階段4發(fā)生異常,由于主庫(kù)進(jìn)入了commit階段,但是binlog尚未發(fā)送到從庫(kù).在主庫(kù)重啟后仍然會(huì)將這個(gè)事務(wù)發(fā)送到從機(jī).
• 在階段5,6,7發(fā)生異常,由于從庫(kù)已經(jīng)收到了binlog,只要主庫(kù)重啟后即可達(dá)到主庫(kù)和備庫(kù)數(shù)據(jù)一致的效果.

通過(guò)以上分析,無(wú)損復(fù)制模式下只有在階段4發(fā)生宕機(jī)會(huì)導(dǎo)致恢復(fù)后雙主數(shù)據(jù)不一致,因?yàn)楫?dāng)在此階段發(fā)生宕機(jī),該事務(wù)并沒(méi)有發(fā)送至從庫(kù),但是主庫(kù)已提交至Binlog和Redolog,如果此時(shí)業(yè)務(wù)切至從庫(kù),主庫(kù)恢復(fù)后會(huì)繼續(xù)將事務(wù)commit并同步到從庫(kù),但是由于從庫(kù)上已經(jīng)有了新事務(wù),很可能會(huì)和此事務(wù)產(chǎn)生沖突(如主鍵沖突),從而導(dǎo)致雙主數(shù)據(jù)不一致；為了解決此宕機(jī)時(shí)臨界事務(wù)問(wèn)題,我們通過(guò)內(nèi)核層面在主庫(kù)重啟recovery階段作了如下調(diào)整：有選擇性的commit并復(fù)制到從庫(kù)部分事務(wù),回滾掉沒(méi)有同步到原從庫(kù)的事務(wù)及Truncate掉binlog中相應(yīng)的event,整個(gè)過(guò)程如下圖：

如上圖所示,主庫(kù)在恢復(fù)后,會(huì)向從庫(kù)或者proxy詢問(wèn)從本庫(kù)同步過(guò)去的最后一條事務(wù)的Binlog位置,并以此為基礎(chǔ)回滾掉該Binlog位置之后的臨界事務(wù).

2、半同步退化問(wèn)題?

由于網(wǎng)絡(luò)抖動(dòng)以及從庫(kù)硬件故障等問(wèn)題會(huì)導(dǎo)致半同步退化為異步,如果在此情況下主庫(kù)發(fā)生宕機(jī)并發(fā)生切換,會(huì)導(dǎo)致數(shù)據(jù)丟失,對(duì)于很多數(shù)據(jù)敏感的業(yè)務(wù)(如金融)后果是非常嚴(yán)重的；因此當(dāng)半同步復(fù)制退化,整個(gè)集群是不可以容災(zāi)切換業(yè)務(wù)的；但是如果主機(jī)宕機(jī)無(wú)法ssh登陸,我們又如何確定主從是否退化,從庫(kù)數(shù)據(jù)是否和主庫(kù)一致呢.

為了解決此問(wèn)題,防止錯(cuò)誤的切換導(dǎo)致數(shù)據(jù)丟失,UDB通過(guò)在proxy和mysql之間以及主從之間增加鏈接通道,proxy和myql會(huì)用專門(mén)的線程通過(guò)此鏈接通道同步事務(wù)信息,如果主庫(kù)發(fā)生宕機(jī),從庫(kù)可以在本地緩存和遠(yuǎn)端proxy獲取同步事務(wù)信息,并使用該事務(wù)信息作為從機(jī)是否可以切換的依據(jù),如下圖：

同時(shí)為了提高可用性,應(yīng)對(duì)短時(shí)間網(wǎng)絡(luò)抖動(dòng)后造成雙主長(zhǎng)時(shí)間數(shù)據(jù)不一致,udb在網(wǎng)絡(luò)恢復(fù)后,會(huì)額外啟動(dòng)一個(gè)復(fù)制鏈路來(lái)追補(bǔ)落后的數(shù)據(jù),而原半同步復(fù)制鏈路繼續(xù)用于復(fù)制實(shí)時(shí)事務(wù),這樣不僅可以加快復(fù)制數(shù)據(jù)效率,而且避免了由于從庫(kù)負(fù)載過(guò)高永遠(yuǎn)恢復(fù)半同步的風(fēng)險(xiǎn).

3、如何保證proxy的高可用

通過(guò)以上問(wèn)題及UDB相應(yīng)解決方案的分析,大家可以看出Proxy在整個(gè)架構(gòu)中扮演著極其重要的角色,不僅負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā),同時(shí)為數(shù)據(jù)一致性和可用性提高保障；因此大家一定會(huì)問(wèn)如果Proxy宕機(jī)怎么辦,為了解決Proxy高可用問(wèn)題,UDB這邊對(duì)Proxy模塊也采用了一主一備模式,如下圖：

主Proxy宕機(jī)觸發(fā)容災(zāi)

當(dāng)圖中左路主Proxy宕機(jī)后,ProxyMaster模塊會(huì)觸發(fā)容災(zāi)處理過(guò)程,此時(shí)ProxyMaster會(huì)將虛擬IP重新綁定至Proxy(backup)并自動(dòng)啟動(dòng),啟動(dòng)后Proxy(backup)會(huì)重新鏈路至原MasterDB,以保證業(yè)務(wù)不間斷,而ProxyMaster模塊通過(guò)ZK服務(wù)分布在多個(gè)服務(wù)器上,有效的保證了Proxy的可用性.

當(dāng)然除了該雙主技術(shù)架構(gòu)外,為了保障服務(wù)的高可用,UDB在運(yùn)維監(jiān)控等層面也做了很多工作,通過(guò)對(duì)從硬件、操作系統(tǒng)、數(shù)據(jù)庫(kù)以及網(wǎng)絡(luò)等各個(gè)層面的不間斷監(jiān)控,從而最大程度的及時(shí)捕獲和恢復(fù)數(shù)據(jù)庫(kù)服務(wù)；同時(shí)UDB通過(guò)自研的大型數(shù)據(jù)庫(kù)備份系統(tǒng),能夠應(yīng)對(duì)各種級(jí)別的宕機(jī)故障后的數(shù)據(jù)恢復(fù),從而保障了用戶數(shù)據(jù)的安全可靠性,這里不做過(guò)多贅述,有興趣的同學(xué)可以參考《從爐石傳說(shuō)數(shù)據(jù)庫(kù)故障看云數(shù)據(jù)備份策略》這篇文章.

作者介紹

孫研,UCloud云數(shù)據(jù)庫(kù)UDB團(tuán)隊(duì)核心成員、高級(jí)研發(fā)工程師,帶領(lǐng)團(tuán)隊(duì)對(duì)UDB底層架構(gòu)進(jìn)行重構(gòu),在內(nèi)核方面對(duì)UDB性能和數(shù)據(jù)一致性等方面做了大量深入的工作.數(shù)年來(lái)深耕在云數(shù)據(jù)庫(kù)領(lǐng)域,熱衷于開(kāi)源、分享.

文章來(lái)自微信公眾號(hào)：細(xì)說(shuō)云計(jì)算

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.snjht.com/jiaocheng/4169.html