OceanBase高可用方案

楊傳輝

(阿里巴巴集團，北京 100020)

?

OceanBase高可用方案

楊傳輝

(阿里巴巴集團，北京 100020)

傳統(tǒng)關系數(shù)據(jù)庫基于共享存儲或者主備同步的方式實現(xiàn)高可用.這些方案要么依賴硬件的高可用，但成本高昂；要么無法同時滿足強一致性和高可用性.OceanBase將云計算和數(shù)據(jù)庫兩種技術有機地融合起來，實現(xiàn)了基于Paxos協(xié)議的高可用方案.該方案構建在普通服務器上，成本低廉，且同時滿足強一致性和高可用性.

共享存儲； 主備同步； 高可用； 強一致； Paxos

0 引 言

數(shù)據(jù)庫管理系統(tǒng)廣泛應用于銀行、信用卡交易、商品銷售、航空與鐵路運輸、電信、電力系統(tǒng)、教育、醫(yī)療與健康、電子商務等各個領域.數(shù)據(jù)庫管理系統(tǒng)已經(jīng)成為訂票、金融、電子商務等應用所不可缺失的核心信息系統(tǒng)[1].以“天貓雙十一”購物節(jié)為例，開始搶購的1分鐘內有1千萬買家登錄天貓系統(tǒng).系統(tǒng)1個小時之內的成交金額達到67億元，支付寶支付2 500萬筆[2].以此推算，如果支撐交易的數(shù)據(jù)庫系統(tǒng)出現(xiàn)5分鐘不可用，將會損失成交金額約5.6億元，并損害成百上千萬用戶的體驗.因此，持續(xù)可用是數(shù)據(jù)庫管理系統(tǒng)的核心目標.

傳統(tǒng)數(shù)據(jù)庫的高可用依賴于底層的高可用硬件，如高端服務器和高端存儲等.雖然這些方案部分滿足了高可用需求，然而它們成本高昂，且不可擴展，無法滿足互聯(lián)網(wǎng)業(yè)務應用的需要.互聯(lián)網(wǎng)業(yè)務要求底層的數(shù)據(jù)庫系統(tǒng)構建在普通的服務器上，并假設故障不可避免.這些故障可能是硬件故障，如硬盤故障；也可能是天災，如地震、火災等.

OceanBase[3]高可用方案構建在不可靠的主流PC服務器上，通過軟件實現(xiàn)自動容錯，使得系統(tǒng)內部故障對外部使用者不可見.這種方案成本低廉，且同時滿足強一致性和高可用性.OceanBase的高可用方案使得它能夠被廣泛應用在淘寶、天貓、支付寶等多個阿里巴巴集團核心業(yè)務的生產(chǎn)環(huán)境中.

1 傳統(tǒng)數(shù)據(jù)庫高可用方案

1.1 高可用集群

Oracle的集群方案[4]如圖1所示.多個數(shù)據(jù)庫實例(Node1-Node3)通過高端的存儲區(qū)域網(wǎng)(SAN，Storage Area Network)訪問共享存儲.數(shù)據(jù)庫的數(shù)據(jù)文件和操作日志都需要持久化到共享存儲.當某個數(shù)據(jù)庫實例出現(xiàn)故障時，集群中的其它數(shù)據(jù)庫實例能通過共享存儲來恢復服務.可以看到，數(shù)據(jù)庫的整體可用性取決于共享存儲的可用性.

圖1 Oracle集群方案

為了保證性能，數(shù)據(jù)庫實例和共享存儲之間一般采用專用的InfiniBand網(wǎng)絡，其帶寬可達40 Gbit/s，延遲為1 μs.與之對比，普通的局域網(wǎng)之間的網(wǎng)絡延遲一般為250 μs左右.因此，數(shù)據(jù)庫實例和共享存儲必須部署在同一個數(shù)據(jù)中心內，無法容忍單個數(shù)據(jù)中心整體故障.另外，InfiniBand網(wǎng)絡和共享存儲價格高昂，且容量不夠時很難擴展.

1.2 主備同步

另外一種常見的數(shù)據(jù)庫高可用方案為主備同步[5].

如圖2所示，數(shù)據(jù)庫主機(Primary DataBase)將重做日志(Redo Log)同步到備機(Standby DataBase).主機提供服務，執(zhí)行讀寫事務，備機可以執(zhí)行不要求讀到最新數(shù)據(jù)的讀事務.當主機出現(xiàn)故障時，備機可以替換為主機繼續(xù)提供服務.

主備同步往往分為3種模式：

圖2 Oracle主備同步

? 最大保護模式：任何一個事務必須首先同步到備機，接著在主機執(zhí)行成功，才能應答客戶端成功；

? 最大性能模式：事務只需要在主機執(zhí)行成功，就可以應答客戶端成功；

? 最大可用模式：當備機以及主備之間網(wǎng)絡正常時，采用最大保護模式，即任何一個事務都需要首先同步到備機；當備機或者主備之間網(wǎng)絡出現(xiàn)故障時，退化到最大性能模式，即只需要在主機執(zhí)行成功.

假設采用最大保護模式，當備機或者主備之間網(wǎng)絡出現(xiàn)故障時，無法提供服務，系統(tǒng)的可用性受到影響.假設采用最大性能模式，當主機出現(xiàn)故障時，備機的數(shù)據(jù)往往落后于主機，如果將服務切到備機，可能丟失最后提交的一部分事務，出現(xiàn)數(shù)據(jù)不一致.最大可用模式也有類似的問題，當主機出現(xiàn)時，備機無法知道是否和主機完全一致，如果要求強一致性，也無法將服務切到備機.

1.3 最高可用性

傳統(tǒng)數(shù)據(jù)庫中，可以將高可用集群和主備同步2種方案組合起來，實現(xiàn)最高可用性(MAA，Maximum Availability Architecture)體系結構[6].圖3中有2個數(shù)據(jù)中心，IDC-1為主，IDC-2為備.IDC-1和IDC-2內部通過共享存儲實現(xiàn)高可用集群，IDC-1和IDC-2之間通過主備同步的方式同步操作日志.可以看到，只要IDC-1內部的共享存儲不出現(xiàn)問題，系統(tǒng)都能正常服務.當IDC-1內部的共享存儲出現(xiàn)問題或者IDC-1整體故障，IDC-2和IDC-1之間雖然可能不一致，不過相差不會太多，如果IDC-1永遠無法恢復，可以忍受損失一部分數(shù)據(jù)的代價把IDC-2強制切為主后繼續(xù)提供服務.

總而言之，即使通過高昂的成本實現(xiàn)了最高可用性，當整個數(shù)據(jù)中心或者共享存儲出現(xiàn)故障時，都無法將服務無損地切換到備份的數(shù)據(jù)中心.也就是說，只要保證強一致性，就無法做到數(shù)據(jù)中心容災；只要實現(xiàn)數(shù)據(jù)中心容災，就無法做到強一致性.

2 OceanBase高可用方案

OceanBase高可用方案構建在普通的PC服務器之上，假設硬件故障是常態(tài)，實現(xiàn)時使用了主備強同步策略和分布式選舉協(xié)議.當主機出現(xiàn)問題時，它保證至少有一個備機和主機完全同步，并通過分布式選舉協(xié)議選出唯一的總控節(jié)點執(zhí)行主備切換，既保證了強一致性，又實現(xiàn)了高可用性.

圖3 最高可用性體系結構

2.1 3機房架構

如圖4，OceanBase部署為3個集群，每個集群包含如下4種角色：

圖4 OceanBase 3集群架構

(1) MergeServer：OceanBase的應用接口，支持JDBC/ODBC協(xié)議，負責進行SQL解析并生成執(zhí)行計劃.

(2) ChunkServer：保存存儲于sstable的基線數(shù)據(jù)，并提供讀訪問.為了防止由于ChunkServer故障導致服務不可用甚至數(shù)據(jù)丟失，每個sstable保存了多個副本并分布在不同的ChunkServer上.

(3) RootServer：OceanBase的總控中心，負責ChunkServer/MergeServer的上線、下線管理以及sstable的負載均衡.

(4) UpdateServer：執(zhí)行寫事務、保存修改增量(到內存)、寫重做日志(redo log)(到磁盤)并提供讀服務.

其中，RootServer以及UpdateServer和本文闡述的高可用性方案有關.UpdateServer分為主UpdateServer和備UpdateServer 2種角色.同一時刻，只有一個UpdateServer為主UpdateServer.每個寫事務都需要在主UpdateServer執(zhí)行成功并且同步到至少一臺備UpdateServer，才可以應答客戶端.當主UpdateServer出現(xiàn)故障時，至少有一臺備UpdateServer和主UpdateServer完全同步，可以切換為主UpdateServer繼續(xù)提供服務.

UpdateServer主備切換操作由RootServer來執(zhí)行，同一時刻只有一臺RootServer為主機.當主RootServer出現(xiàn)故障時，需要通過基于Paxos的分布式選舉協(xié)議保證有且只有一臺備RootServer被選為主RootServer繼續(xù)提供服務，從而保證強一致性和高可用性.

2.2 主備強同步

UpdateServer每次執(zhí)行一個寫事務時，都會生成一條操作日志，同步到備機并寫入到本地磁盤，接著在內存中應用事務的修改操作.OceanBase的強同步策略要求至少同步成功一臺備機，才可以應答客戶端.

如圖5，假設DB1為主機，DB2和DB3為備機，DB1包含8個事務，其中，DB2已經(jīng)收到前6個事務，DB3只收到前4個事務.由于前6個事務已經(jīng)同步到DB2，因此認為事務“已提交”，可以應答客戶端；而后面2個事務沒有同步到任何備機，處于“未決”狀態(tài).當DB1出現(xiàn)故障時，OceanBase會選擇日志號最大的備機切換為主機.假設DB2切換為主機，那么，前6個已經(jīng)提交的事務將恢復，后面2個“未決”事務將被回滾；假設DB1再次參與到故障恢復過程并且重新選為主機，那么，后面2個“未決”事務將會被最終提交.

為了提高主備同步的性能，UpdateServer實現(xiàn)了一些優(yōu)化措施，包括：

圖5 OceanBase主備日志同步

(1) 成組提交(group commit)：每次執(zhí)行寫事務都需要將對應的操作日志寫磁盤并同步到備機.成組提交技術將正在并發(fā)執(zhí)行的事務的操作日志打包到一個緩沖區(qū)中，一次性刷盤并同步備機，從而提升數(shù)據(jù)庫系統(tǒng)的整體吞吐量.

(2) 異步化：UpdateServer執(zhí)行寫事務時，除了寫磁盤，還需要同步到多個備機.實現(xiàn)時將寫磁盤以及同步備機操作完全異步化，從而降低事務延時.

(3) 降低鎖粒度：UpdateServer提交事務時需要將并發(fā)執(zhí)行的事務的操作日志拷貝到日志緩沖區(qū)并且保證順序，當海量事務并發(fā)執(zhí)行時，日志緩沖區(qū)的鎖沖突非常嚴重.UpdateServer實現(xiàn)時盡可能降低拷貝日志的鎖粒度，在保證順序的前提下，允許將多個并發(fā)事務的操作日志同時拷貝到日志緩沖區(qū).

2.3 分布式選舉

OceanBase包含多個RootServer，同一個時刻只允許有一個RootServer作為主RootServer提供服務.當主RootServer出現(xiàn)故障或者整個集群重新啟動時，OceanBase通過分布式選舉協(xié)議選出唯一的主RootServer.

分布式選舉協(xié)議往往基于Lamport提出的Paxos協(xié)議[7].Paxos協(xié)議假設：

1. 成員不說假話(非拜占庭式).

2. 單個成員說話不自相矛盾.

3. 任何決議需要“多數(shù)派”同意.

假設有2N+1個成員，那么，N+1個成員構成“多數(shù)派”.如果某個決議得到了“多數(shù)派”的同意，且任何一個成員說話不自相矛盾，那么，顯然不會存在另外一個“多數(shù)派”同意其他的決議.因此，可以證明協(xié)議的正確性.然而，協(xié)議的可終止性無法得到證明，可能出現(xiàn)永遠無法達成一致的情況.另外，Paxos協(xié)議，尤其是多輪Paxos協(xié)議(Multi Paxos)非常復雜，工程上更是難以實現(xiàn).目前已經(jīng)有一些開源的工程實現(xiàn)對Paxos協(xié)議做了很大的簡化，例如Raft[8]，而OceanBase則做得更加徹底.

OceanBase將Paxos協(xié)議改造成如下的“同步模式”.

如圖6，所有成員在同一時刻(T1)“同時”發(fā)起選舉，執(zhí)行步驟如下：

圖6 OceanBase選舉協(xié)議

1. T1時刻：預投票，即每個成員廣播自己的“投票權重”；

2. T2(>T1)時刻：投票，即每個成員向收到的“投票權重”最大者投票；

3. T3(>T2)時刻：計票并廣播，即統(tǒng)計投票，得票過半者當選新主并向所有成員廣播；

4. T4(>T3)時刻：選舉結束，成員接收到新主當選的廣播.

與Paxos協(xié)議類似，新主當選要求獲得“多數(shù)派”同意，因此，最多選出一個新主，協(xié)議的正確性得到證明.另外，由于所有成員“同時”發(fā)起選舉，只要成員之間時鐘偏差不會太大，且“多數(shù)派”工作正常，都能夠選出新主.OceanBase集群采用ntp協(xié)議來做時鐘同步，大部分情況下成員之間的時鐘偏差都在幾毫秒之內，最壞情況下也不會超過100 ms，從而保證選舉協(xié)議是可終止的.

新主當選后，允許在租約有效期內提供服務.當租約快到期時，主機可以發(fā)起“有主選舉”來續(xù)約，使自己再次被選為主.如果主機出現(xiàn)故障，那么，OceanBase會在它的租約過期后發(fā)起新的分布式選舉過程，其他成員可以被選為新主繼續(xù)提供服務.

下面分析協(xié)議的選舉時間.假設成員之間的時鐘偏差最大為Tdiff，網(wǎng)絡來回最大延遲為Tst.那么，某個成員在T1時刻發(fā)送預投票后，其他成員最晚在T1+2*Tdiff+Tst時刻收到預投票. 也就是說，T2等于T1+2*Tdiff+Tst，每個成員收到所有其他在線成員的預投票請求后開始投票，保證不會錯過任何一個成員的預投票請求.同理，T3等于T2+2*Tdiff+Tst，每個成員收到所有其他在線成員的投票請求后開始計票，保證不會錯過任何一個成員的投票請求.T4等于T3+2*Tdiff+Tst，每個成員收到所有其他在線成員的廣播請求后選舉過程結束.綜上所述，T4等于T1+6*Tdiff+3* Tst，一次選舉過程耗時Telect等于6*Tdiff+3* Tst.之前已經(jīng)提到，ntp協(xié)議保證時鐘偏差最大不超過100 ms，即Tdiff等于100 ms；而網(wǎng)絡延遲Tst往往不超過200 ms，可以算出Telect等于6*Tdiff+3* Tst= 1 200ms.選舉協(xié)議額外保留200 ms，得到擴展的選舉時間Telect2等于1 200 ms + 200 ms = 1 400 ms，即1.4 s.

OceanBase租約有效期為4倍選舉時間，即5.6 s；選舉周期為5倍選舉時間，即7 s.當主機出現(xiàn)故障，OceanBase會等到它的租約過期后，在選舉周期的整數(shù)倍時間點發(fā)起新的分布式選舉過程.因此，最壞情況下，從主機故障到選出新主的時間為5.6 s(租約有效期) + 7 s(選舉周期) + 1.2 s(選舉時間)，即13.8 s.

2.4 優(yōu)缺點

Google Spanner和Raft系統(tǒng)中都實現(xiàn)了基于Paxos協(xié)議的高可用方案.其中，Spanner[9]中采用原生的Paxos協(xié)議，Raft對協(xié)議進行了簡化.OceanBase進一步將Paxos協(xié)議由“異步模式”改進為“同步模式”，工程實現(xiàn)上更加簡單，且能夠保證最長約2個選舉周期就能選出新主.無論是Spanner還是Raft，都無法做到這一點.然而，OceanBase選舉協(xié)議依賴時鐘同步，要求多臺服務器之間的時鐘偏差不能過大，底層的ntp服務需要嚴格保證這一點.

3 結 論

本文介紹了傳統(tǒng)數(shù)據(jù)庫的高可用方案，分析了其中的不足，并給出了OceanBase高可用方案以及其中的幾個性能優(yōu)化措施.OceanBase高可用方案同時滿足強一致性和高可用性，且成本低廉，是未來數(shù)據(jù)庫高可用的趨勢.

[1] RAMAKRISHNAN R, GEHRKE J. Database management systems[M]. 3rd ed.[s.l]: McGraw-Hill, 2003.

[2] 雙十一戰(zhàn)記[EB/OL].http://ucwap.ifeng.com/tech/hulianwang/news?aid=73824780.

[3] OceanBase開源[EB/OL].http://alibaba.github.io/oceanbase/.

[4] GOPALAKRISHNAN K. Oracle database 11g oracle real application clusters handbook[M]. 2nd ed.[s.l]:Oracle Press, 2011.

[5] Oracle data guard[EB/OL].http://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm.

[6] Oracle maximum availability architecture[EB/OL]. [2014-08-31].http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdf?ssSourceSiteId=ocomuk.

[7] LAMPORT L. The part-time parliament[J]. ACM TOCS, 1998, 16(2): 133-169.

[8] ONGARO D, OUSTERHOUT J. In search of an understandable consensus algorithm[C]//Proceedings of the 2014 USENIX Annual Technical Conference. 2014: 305-319.

[9] CORBETT J C, DEAN J, EPSTEIN M, et al. Spanner: Google’s globally-distributed database[C]. OSDI’12, 2012:251-264.

(責任編輯 林 磊)

High availability solution of OceanBase

YANG Chuan-hui

(AlibabaInc.,Beijing100020,China)

Shared storage or master-slave replication is used in traditional RDBMS to achieve high availability. The first solution relies on high available hardware, and so are of high cost, while the second solution cannot meet the requirements of strong consistency and high availability concurrently. OceanBase combines cloud computing and database technology. Its high availability solution is based on Paxos protocol. This solution is built on top of commodity machine. It meets requirements of both strong consistency and high availability with low cost.

shared storage; master-slave replication; high availability; strong consistency; Paxos

1000-5641(2014)05-0173-07

2014-06

楊傳輝，男，阿里巴巴集團技術專家，研究方向為分布式數(shù)據(jù)庫. E-mail: rizhao.ych@alipay.com.

TP31

A

10.3969/j.issn.1000-5641.2014.05.015