亚洲欧美日韩综合系列在线_91精品人妻一区二区_欧美大肥婆一级特大AA片_九色91视频免费观看_亚洲综合国产精品_av中文字幕在线不卡_久久精品色综合网_看黄色视频的软件_无卡无码高清中文字幕码2024_亚洲欧美日韩天堂网

OceanBase數(shù)據(jù)庫高可用及容災(zāi)方案詳細介紹

1     前言

眾所周知，作為生產(chǎn)系統(tǒng)中極為關(guān)鍵的核心軟件，數(shù)據(jù)庫產(chǎn)品的高可用性一直是使用者極為關(guān)注的功能點。尤其是在金融這樣一個特殊的領(lǐng)域里，無論是從監(jiān)管的要求來看，還是從業(yè)務(wù)需求本身來看，都需要提供24*7持續(xù)不間斷的服務(wù)，這就對金融行業(yè)中數(shù)據(jù)庫產(chǎn)品的高可用性提出了很高的要求，不但需要應(yīng)對個別硬件故障的情況，還必須能夠應(yīng)對機房整體故障和城市災(zāi)難等極端情況，保證數(shù)據(jù)庫在各種意外情況下都能持續(xù)提供服務(wù)，即具備機房級容災(zāi)能力和城市級容災(zāi)能力。本文的主要目的，是總結(jié)和回顧一下傳統(tǒng)數(shù)據(jù)庫產(chǎn)品常用的高可用及容災(zāi)方案，并向讀者介紹一下以O(shè)ceanBase為代表的分布式數(shù)據(jù)庫常用的方案，希望能夠起到拋磚引玉的作用，引發(fā)讀者關(guān)于新型分布式架構(gòu)下高可用及容災(zāi)方案的思考。

2     背景介紹

首先，我們回顧一下傳統(tǒng)的關(guān)系型數(shù)據(jù)庫產(chǎn)品（如Oracle、DB2等）常用的高可用及容災(zāi)技術(shù)。我們知道，傳統(tǒng)數(shù)據(jù)庫產(chǎn)品最初都是單點架構(gòu)，并不具備高可用設(shè)計，更多的是基于高端硬件產(chǎn)品滿足“硬件可靠”的假設(shè)。隨著時間的推移，傳統(tǒng)數(shù)據(jù)庫產(chǎn)品先后推出了采用“主從復(fù)制”架構(gòu)的高可用方案，比如Oracle的Data Guard技術(shù)和DB2的HADR技術(shù)，其主要思路是：在原有的單數(shù)據(jù)庫節(jié)點（主節(jié)點）之外再增加一個對等的數(shù)據(jù)庫節(jié)點（從節(jié)點），通過數(shù)據(jù)庫層面的復(fù)制技術(shù)（通常是日志復(fù)制）將主節(jié)點產(chǎn)生的數(shù)據(jù)實時復(fù)制到從節(jié)點；正常情況下從節(jié)點不提供對外服務(wù)，當(dāng)主節(jié)點發(fā)生故障時，在從節(jié)點上執(zhí)行“切主”動作將從節(jié)點變成主節(jié)點，繼續(xù)提供服務(wù)。在主從節(jié)點的部署方式上，除了本地單機房部署外，往往也支持同城災(zāi)備部署和異地災(zāi)備部署，因此也就具備了機房級容災(zāi)和城市級容災(zāi)的能力。很多新興的數(shù)據(jù)庫產(chǎn)品（如MySQL）也是采用“主從復(fù)制”模式來實現(xiàn)高可用及容災(zāi)特性。

除了數(shù)據(jù)庫層面的主從復(fù)制技術(shù)之外，還有一些在底層硬件上實現(xiàn)的高可用方案，比如在主機層面用HACMP技術(shù)以應(yīng)對主機故障，或者在存儲層面采取復(fù)制技術(shù)（比如FlashCopy）來提供數(shù)據(jù)冗余等。這些技術(shù)雖然也可以用來實現(xiàn)高可用和容災(zāi)能力，但和應(yīng)用的整合度不高，會使災(zāi)難切換方案變得很復(fù)雜，并且會有相對較長的故障恢復(fù)時間（RTO），所以通常不是數(shù)據(jù)庫用戶的首選。

最后，近些年還出現(xiàn)了一些支持異種數(shù)據(jù)庫之間相互復(fù)制數(shù)據(jù)的產(chǎn)品，比如IBM CDC和Oracle Golden Gate（OGG）。這些產(chǎn)品的特點是比較靈活，可以支持異種數(shù)據(jù)庫之間的數(shù)據(jù)復(fù)制，也可以指定只復(fù)制數(shù)據(jù)庫中的部分對象（比如只復(fù)制指定幾張數(shù)據(jù)表的數(shù)據(jù)）。但這些產(chǎn)品的缺點也很明顯：首先相對于數(shù)據(jù)庫主從復(fù)制來說時延偏大，通常會達到秒級以上，而且往往做不到數(shù)據(jù)庫層面100%的完全復(fù)制。因此，這種方式通常作為不同數(shù)據(jù)庫產(chǎn)品之間做數(shù)據(jù)“準”實時同步的手段，而不會作為數(shù)據(jù)庫產(chǎn)品實現(xiàn)高可用及容災(zāi)的手段。

稍微總結(jié)一下，傳統(tǒng)的數(shù)據(jù)庫產(chǎn)品通常會采用下面的方法實現(xiàn)高可用：

?2?  在主機層面實施高可用（HACMP）架構(gòu)，以應(yīng)對主機故障所帶來的影響（非首選方案）。

?2?  在存儲層面采用數(shù)據(jù)復(fù)制技術(shù)（比如FlashCopy）來提供數(shù)據(jù)冗余，以應(yīng)對存儲損壞所帶來的影響（非首選方案）。

?2?  在數(shù)據(jù)庫層面提供“主從復(fù)制”技術(shù)（首選方案）。

?2?  第三方數(shù)據(jù)復(fù)制產(chǎn)品，如CDC、OGG等（很少采用）。

通過上述的各種技術(shù)，尤其是數(shù)據(jù)庫“主從復(fù)制”技術(shù)，使得意外發(fā)生時數(shù)據(jù)庫可以在一定時間內(nèi)恢復(fù)服務(wù)，并且大部分數(shù)據(jù)不會丟失，具備了一定的高可用及容災(zāi)能力。但是，上面這些技術(shù)也有一些難以克服的缺點，以“主從復(fù)制”技術(shù)為例，雖然它是傳統(tǒng)數(shù)據(jù)庫里最先進也是最常用的高可用及容災(zāi)技術(shù)，但還是有一些無法解決的問題：

?2?  通常情況下無法做到RPO=0，即主節(jié)點發(fā)生故障或者災(zāi)難時有交易數(shù)據(jù)的損失。

可能有的讀者會說：你說錯了！主從復(fù)制技術(shù)也能實現(xiàn)RPO=0。

是的，理論上講主從復(fù)制技術(shù)是可以利用強同步模式（比如Oracle Data Guard中采用Max Protection模式，或者DB2 HADR中采用Sync模式）做到RPO=0，但實際應(yīng)用中，像銀行核心系統(tǒng)這樣的關(guān)鍵業(yè)務(wù)里卻不會采用。為什么呢？因為這種模式將主節(jié)點和從節(jié)點以及主從節(jié)點之間的網(wǎng)絡(luò)環(huán)境緊緊地綁在了一起，主節(jié)點的穩(wěn)定性將不再由它自己決定，而要同時看從節(jié)點和網(wǎng)絡(luò)環(huán)境的臉色：一旦從節(jié)點或者網(wǎng)絡(luò)環(huán)境稍微抖動一下，主節(jié)點的性能就會受到直接影響。如果主節(jié)點和從節(jié)點之間是跨機房甚至跨城市部署，發(fā)生這種問題的概率會更大，影響也會變得更加顯著。從某種程度上講，和單節(jié)點模式相比，這種模式下主節(jié)點的穩(wěn)定性不但沒有增加，反而是降低了。如果有銀行的朋友在關(guān)鍵業(yè)務(wù)中應(yīng)用過Oracle Data Guard或者DB2 HADR，對強同步模式所帶來的問題應(yīng)該是深有體會的。

?2?  RTO相對較大，通常以十分鐘甚至小時為計算單位，會給業(yè)務(wù)帶來比較大的損失。

造成這一情況的根本原因，是“主從復(fù)制”模式下從節(jié)點不具備自動切主的能力。

由于“主從復(fù)制“模式中缺少第三方仲裁者的角色，當(dāng)主從節(jié)點之間的心跳信號異常時，從節(jié)點無法靠自己判斷到底是主點故障了，還是主從之間的網(wǎng)絡(luò)故障了。此時，如果從節(jié)點認為是主節(jié)點故障而將自己自動切換成主節(jié)點，就極容易導(dǎo)致“雙主”、“腦裂”（brain-split）的局面，對用戶來說這是絕對無法接受的結(jié)果。所以數(shù)據(jù)庫“主從復(fù)制”技術(shù)從來不會提供“從節(jié)點自動切換為主節(jié)點”的功能，一定要由“人”來確認主節(jié)點確實故障了，并手工發(fā)起從節(jié)點的切主動作，這就大大增加了系統(tǒng)恢復(fù)的時間（RTO）。

聊完了傳統(tǒng)數(shù)據(jù)庫的高可用技術(shù)，我們再來看看另一種逐漸被越來越多的技術(shù)廠商所采用的技術(shù)，那就是分布式多副本數(shù)據(jù)一致性技術(shù)，通常是基于Paxos協(xié)議或者Raft協(xié)議來實現(xiàn)。這種技術(shù)會將數(shù)據(jù)保存在多份副本上，每一次對數(shù)據(jù)的修改操作都會強同步到多數(shù)派副本上，在保證了數(shù)據(jù)冗余的同時，不再像“主從復(fù)制”技術(shù)那樣依賴某個數(shù)據(jù)節(jié)點的穩(wěn)定性，從而消除了傳統(tǒng)主從復(fù)制技術(shù)下從節(jié)點給主節(jié)點帶來的風(fēng)險。同時，在主節(jié)點故障的情況下，其余節(jié)點會自動選舉出新的主節(jié)點以實現(xiàn)高可用（個別從節(jié)點故障則完全不影響服務(wù)），整個過程非?？焖偾彝耆珶o需人工干預(yù)。因此，這種技術(shù)不僅能保證RPO=0，而且大大減小了RTO，相比傳統(tǒng)“主從復(fù)制”技術(shù)來說可以提供更強大的高可用能力。

此外，為了抵御機房級災(zāi)難和城市級災(zāi)難，可以將多份副本分散部署在多個機房里甚至多個城市中，以避免機房級災(zāi)難或者城市級災(zāi)難損毀多數(shù)派副本。這樣就具備了機房級容災(zāi)和城市級容災(zāi)的能力，進一步加強了高可用的能力。

3     OceanBase常用的高可用及容災(zāi)方案

OceanBase數(shù)據(jù)庫從誕生之初，就利用Paxos協(xié)議在底層實現(xiàn)了多副本數(shù)據(jù)一致性，具有上述“RPO=0、低RTO（通常在30s以下）、故障時自動切換”的優(yōu)勢。而經(jīng)過多年實際應(yīng)用場景的歷練后，尤其是像支付寶、淘寶、網(wǎng)商銀行這種高并發(fā)、高訪問量、24*7持續(xù)交易場景的磨練，OceanBase數(shù)據(jù)庫已經(jīng)摸索出一套完整的、經(jīng)過實踐檢驗的高可用及容災(zāi)方案。下面我們就結(jié)合OceanBase數(shù)據(jù)庫的實踐經(jīng)驗，向大家介紹一下分布式數(shù)據(jù)常用的一些高可用及容災(zāi)方案。

特別說明一下，在后文的示意圖中會有一些經(jīng)常用到的名詞，在此先做個簡單的說明，以方便大家理解：

?2?  OBServer

一個OBServer指的是一個獨立提供服務(wù)（share-nothing）的OceanBase數(shù)據(jù)庫節(jié)點，這是一個軟件層面的定義。但通常一臺物理服務(wù)器上只有一個OBServer，因此也可以認為一個OBServer等同于OceanBase數(shù)據(jù)庫集群的一個物理節(jié)點。

?2?  Zone

這是OceanBase數(shù)據(jù)庫的一個內(nèi)部概念。一個Zone是一個或者一些OBServer組成的邏輯集合，一個Zone里的所有OBServer都在一個機房內(nèi)。

從分布式多副本數(shù)據(jù)一致性協(xié)議的角度來看，可以認為一個Zone就是OceanBase數(shù)據(jù)庫集群的一個“副本”，如果是三副本架構(gòu)那就會有三個Zone。

?2?  IDC

IDC就是大家通常理解的“機房”的概念，一個IDC就代表一個機房。

1.1   單機房3副本

這是最簡單的一種方案，在一個機房內(nèi)找足夠多的機器，把它們劃分成3個Zone，每個Zone里一份副本。

這種方案具備一定程度的高可用能力，可抵御個別硬件故障，比如在個別服務(wù)器宕機、個別硬盤損壞等情況下，數(shù)據(jù)庫集群還能持續(xù)提供服務(wù)。此外，這種方案具有部署方便，成本低的特點，只要有一個機房，機房內(nèi)有足夠多的聯(lián)網(wǎng)機器，就可以部署了。

但這種方案也有一個非常明顯的劣勢：不具備容災(zāi)能力。如果發(fā)生機房級災(zāi)難或者城市級災(zāi)難，首先會導(dǎo)致交易停止，而極端情況下（比如機房所有機器損毀）甚至?xí)?dǎo)致數(shù)據(jù)丟失。

綜合來看，這種方案雖然部署方便，也具備高可用特性，但其容災(zāi)的能力卻是最低的，對于具有容災(zāi)要求的系統(tǒng)來說顯然是不適合的。如果用戶的硬件條件有限，只能提供一個機房，并且用戶對系統(tǒng)的容災(zāi)能力沒有要求，那么這種方案是一個非常合適的選擇。

1.2   同城3機房3副本

同樣是一個城市內(nèi)部署3副本，這種方案相對于“單機房3副本”來說就更進了一步：在同一城市內(nèi)找3個不同的機房，每個機房內(nèi)部署1個Zone（1份副本），形成一個跨機房部署的數(shù)據(jù)庫集群。

由于分布式多副本數(shù)據(jù)一致性協(xié)議要將每一個事務(wù)的數(shù)據(jù)強同步到多數(shù)派副本中，這種部署模式下必然導(dǎo)致頻繁的跨機房同步操作。為了保證數(shù)據(jù)庫的寫性能，對機房之間的網(wǎng)絡(luò)質(zhì)量有比較高的要求，通常要求任何兩個機房之間的網(wǎng)絡(luò)時延不超過2毫秒（ms）。

（P.S. 后面所有關(guān)于“同城機房”的描述中，默認都有類似的網(wǎng)絡(luò)要求，后文就不再贅述了）

相對于“單機房3副本”來說，這種方案的優(yōu)勢是很明顯的：除了可以抵御個別硬件故障，還可以抵御機房級災(zāi)難：任何一個機房遇到災(zāi)難，都不會導(dǎo)致交易停止或者數(shù)據(jù)丟失。

不過，并不是每一個用戶都能夠提供“同城三機房”的部署條件。即使是高端企業(yè)級用戶，往往也只具備同城2機房（主機房+同城災(zāi)備機房）的條件，因此3機房對用戶的基礎(chǔ)設(shè)施來說提出了一定的挑戰(zhàn)，也增加了用戶的部署成本。如果考慮到上面說的任意2個機房之間都要做到“網(wǎng)絡(luò)低延時”，那成本會進一步增加。因此，在考慮這種部署方案時，要事先和用戶做好充分的溝通，確保用戶能提供符合要求的基礎(chǔ)設(shè)施。最后還要指出的一點就是，這種方案仍然不具備城市級容災(zāi)的能力，如果發(fā)生城市級災(zāi)難，還是會導(dǎo)致交易停止，甚至有數(shù)據(jù)丟失的風(fēng)險。

綜合來看，如果用戶能夠提供同城3機房的硬件設(shè)施，并且沒有城市級容災(zāi)的要求，那么推薦使用這種方案，可以在城市內(nèi)提供非常好的高可用及容災(zāi)能力。事實上，OceanBase數(shù)據(jù)庫的一些外部企業(yè)級客戶就是采用了這種部署方式，收到了很好的效果。

如果用戶暫時只具備同城2機房的條件，那么可以考慮在城市內(nèi)租借一個機房以滿足“同城3機房”的條件，其成本相對于建設(shè)一個全新IDC來說還是低了很多。甚至可以只為個別數(shù)據(jù)庫集群租借一個同城機房內(nèi)的部分機柜，這樣就進一步降低了成本，對企業(yè)級用戶來說這個成本應(yīng)該還是在可接受范圍內(nèi)的。

1.3   3地3機房5副本

前面介紹的幾種方案中，提到了機房內(nèi)高可用能力和機房級容災(zāi)能力，但是都無法抵御城市級災(zāi)難。下面向大家介紹一種具備城市級容災(zāi)能力的方案：3地3機房5副本方案。

這種方案相對來說要復(fù)雜一些。首先需要有3個城市，每個城市各有1個機房，利用這3個機房組成一個跨機房部署的OB集群。其次，和前面“同城3機房3副本”的方案類似，這種方案對不同機房間的網(wǎng)絡(luò)質(zhì)量是有一定要求的，通常來說需要滿足下面的條件：

1）有2個城市的距離相對較近（比如杭州和上海），它們之間的網(wǎng)絡(luò)時延低于10毫秒（ms）。這2個城市的機房中各部署2個Zone（副本）。

2）第3個城市和前兩個城市的距離相對較遠（比如深圳），它和前2個城市之間的網(wǎng)絡(luò)時延應(yīng)保證在30毫秒（ms）內(nèi)。這個城市的機房內(nèi)部署1個Zone（副本）。

在這種部署模式中，距離較近的2個城市有2個IDC，合計4份副本，構(gòu)成了Paxos協(xié)議要求的多數(shù)派，因此日常寫交易中的強同步操作會集中在這2個城市中，不會涉及到距離較遠的第3個城市，有效避免了遠距離RPC對交易性能帶來的影響。如果2個距離較近的城市中有任何一個Zone發(fā)生故障，剩下的3個Zone依舊構(gòu)成多數(shù)派，還是不會涉及到距離較遠的第3個城市，性能不會受到影響。如果這2個城市中有1個城市發(fā)生了機房級災(zāi)難或者城市級災(zāi)難，剩下的1個城市和距離較遠的第3個城市合在一起還有3個Zone，依舊構(gòu)成多數(shù)派，還是可以繼續(xù)提供服務(wù)，但此時遠距離RPC操作將不可避免，性能也會因此而受到影響。因此，這種方案可以全方位抵御個別硬件故障、機房級災(zāi)難和城市級災(zāi)難，提供最高級別的高可用性，使數(shù)據(jù)安全性得到了最大程度的保障。

不過，這種方案雖然能夠提供全面的數(shù)據(jù)安全性保護，在實際部署中也會面臨一些問題和挑戰(zhàn)。首先，需要在3個城市內(nèi)各有一個機房，3個城市之間要滿足“2近1遠”，而且相互之間的網(wǎng)絡(luò)時延也要滿足一定條件（詳見前文描述），可以說這對用戶的基礎(chǔ)設(shè)施條件提出了非常大的挑戰(zhàn)，即使對高端企業(yè)級用戶來說，也很難滿足這個條件，最多只具備2地3機房的條件。另外，5副本相對于3副本來說增加了2個副本，進一步提高了硬件成本，也加大了這個方案的難度。

在實際應(yīng)用中，如果用戶對SLA提出了最高要求，需要抵御機房級災(zāi)難和城市級災(zāi)難，并且希望做到“RPO=0、低RTO、故障時自動切換”，那么此方案將是不二之選。事實上，網(wǎng)商銀行的數(shù)據(jù)庫集群部署就是采用這種架構(gòu)，支付寶中的部分核心數(shù)據(jù)也是采用了這種架構(gòu)，它們?yōu)闃I(yè)務(wù)提供了最佳的數(shù)據(jù)安全性保障。

對國內(nèi)的企業(yè)級用戶來說，在短期內(nèi)恐怕還很難滿足這種方案的基礎(chǔ)設(shè)施要求。但目前只有3城市的部署架構(gòu)才能在城市級災(zāi)難時做到“RPO=0、低RTO、故障時自動切換”，因此從長遠考慮可以在基礎(chǔ)設(shè)施層面提前有所規(guī)劃。

1.4   同城2機房3副本

前面介紹過，如果只需滿足機房級容災(zāi)的要求，那么可以考慮“同城3機房3副本”的方案，以抵御個別硬件故障和機房級災(zāi)難。但由于歷史原因，很多企業(yè)用戶都建設(shè)了“同城2機房（主機房+同城災(zāi)備機房）”的基礎(chǔ)設(shè)施，卻很少有用戶具備“同城3機房”的條件。此時雖然可以租用一個同城機房來滿足3機房條件，但如果用戶真的找不到合適的第3機房，是否就不能在2機房中部署OceanBase數(shù)據(jù)庫集群了呢？

其實，這種情況下還是可以利用2機房來完成部署的，只要在主機房中部署2個Zone，同城災(zāi)備機房中部署1個Zone，就構(gòu)成了一個跨機房部署的數(shù)據(jù)庫集群。

這種部署模式下，主機房內(nèi)的2個Zone構(gòu)成了多數(shù)派，因此日常的寫交易都會在主機房內(nèi)部完成數(shù)據(jù)強同步，可以保證最佳性能。同時，這種方案也可抵抗個別硬件故障，如個別服務(wù)器宕機、個別硬盤損壞等情況。

但如果主機房發(fā)生機房級災(zāi)難，那么整個數(shù)據(jù)庫集群只剩下同城災(zāi)備機房的1個Zone，不再滿足多數(shù)派條件，無法繼續(xù)提供服務(wù)。因此這種方案是不能抵御機房級災(zāi)難的，只是在同城災(zāi)備機房中保留了一份數(shù)據(jù)，以后可以將數(shù)據(jù)恢復(fù)出來（但RPO>0，數(shù)據(jù)會有少量丟失），避免了數(shù)據(jù)全部丟失的情況。

綜合來看，“同城2機房”的條件下，如果擁有多數(shù)派副本的機房（通常是主機房）發(fā)生災(zāi)難，剩下的一個機房無法單獨提供服務(wù)（這是由分布式多副本數(shù)據(jù)一致性協(xié)議的理論所決定的）。從高可用的角度來看，這種方案不具備機房級容災(zāi)的能力，只是避免了數(shù)據(jù)全部丟失的風(fēng)險，這個結(jié)果大大降低了同城災(zāi)備機房的實際意義。

在實際應(yīng)用中，OceanBase數(shù)據(jù)庫基本不會采用這種方案。相比之下，“同城3機房3副本”方案具備提供機房級容災(zāi)的能力，能提供更強的高可用性，是一個更好的選擇。考慮到增加第3個機房為用戶帶來的額外成本，OceanBase數(shù)據(jù)庫還提供了“日志副本”技術(shù)：用戶可以在已有的2個機房中各部署1個普通副本，在第3個（新增加的）機房中部署1個日志副本。相對于普通副本來說，日志副本可以顯著降低存儲成本，這樣可以在完全不影響RPO的情況下降低第3個機房的擁有成本，減小了用戶部署第3個機房的難度。

1.5   2地3機房5副本

前面介紹過，“3地3機房5副本”的方案可以提供最高級別的高可用性，可以抵御個別硬件故障、機房級災(zāi)難和城市級災(zāi)難等各種情況。但我們同時也提到了，傳統(tǒng)企業(yè)用戶很少能滿足“3地3機房”的要求，很多企業(yè)用戶只具備 “2地3機房（主機房+同城災(zāi)備機房+異地災(zāi)備機房）”的條件。那么這種情況下，分布式數(shù)據(jù)庫是否能利用“2地3機房”完成部署呢？

事實上，這種情況下OceanBase也可以完成數(shù)據(jù)庫集群的部署，只要在主機房和同城災(zāi)備機房中各部署2個Zone，在異地災(zāi)備機房中部署1個Zone，就構(gòu)成了一個跨機房部署的數(shù)據(jù)庫集群。

從架構(gòu)上看，這種部署方案和“3地3機房5副本”方案有類似之處，可以抵御個別硬件故障和機房級災(zāi)難（讀者可參照前面“3地3機房5副本”方案的描述做推理，具體過程這里就不詳述了）。

但是和“3地3機房5副本”相比，這種方案缺少了城市級容災(zāi)的能力：一旦主機房和同城災(zāi)備機房所在的城市發(fā)生災(zāi)難，剩下的異地災(zāi)備機房只有1個Zone，不再滿足多數(shù)派條件，無法繼續(xù)提供服務(wù)，只是在異地災(zāi)備機房中保留了一份數(shù)據(jù)，以后可以將數(shù)據(jù)恢復(fù)出來（但RPO>0，數(shù)據(jù)會有少量丟失），避免了數(shù)據(jù)全部丟失的情況。

綜合來看，“2地3機房”的條件下，如果擁有主機房和同城災(zāi)備機房的城市發(fā)生災(zāi)難，剩下的一個城市無法單獨提供服務(wù)。從高可用的角度來看，這種方案不具備城市級容災(zāi)的能力，只是避免了數(shù)據(jù)全部丟失的風(fēng)險，這個結(jié)果大大降低了異地災(zāi)備機房的實際意義。

在實際應(yīng)用中，OceanBase數(shù)據(jù)庫基本不會采用這種方案。相比之下，“3地3機房5副本”方案具備城市級容災(zāi)的能力，能提供更強的高可用性，是一個更好的選擇。此外，還可以進一步利用前文提到的“日志副本”技術(shù)：用戶可以在已有的2個城市中各部署2個普通副本，在第3個（新增加的）城市中部署1個日志副本，這樣可以在完全不影響RPO的情況下降低第3個城市中機房的擁有成本，減小了用戶在第3個城市中部署機房的難度。

最后，如果用戶實在無法找到第3個城市來部署機房，但同時可以接受“發(fā)生城市級災(zāi)難時RPO>0”的代價，那么可以在兩個城市之間采取“集群間數(shù)據(jù)復(fù)制”的方法（后文有詳細的介紹）。這種方式的弊端很明顯，遇到城市級災(zāi)難時會有“RPO>0，不能自動切主導(dǎo)致RTO較長”的問題，但它可以利用2個城市實現(xiàn)城市級（有損）容災(zāi)，減小了部署的難度。如果采用此方案的話，“主”城市應(yīng)該采用“同城3機房3副本”的架構(gòu)，以提供機房級容災(zāi)的能力。

1.6   集群間數(shù)據(jù)復(fù)制

這種方案類似傳統(tǒng)數(shù)據(jù)庫的“主從復(fù)制”方案，通過數(shù)據(jù)復(fù)制軟件將一個OceanBase數(shù)據(jù)庫集群的數(shù)據(jù)復(fù)制到另一個（或者多個）OceanBase數(shù)據(jù)庫集群，以應(yīng)對單個OceanBase數(shù)據(jù)庫集群的故障。通常來說，不同的OceanBase數(shù)據(jù)庫集群會部署在不同的IDC中，以應(yīng)對機房級災(zāi)難和城市級災(zāi)難。

這種方式主要是為了應(yīng)對以下幾種情況：

?2?  只有2個機房的條件下，希望能夠具備機房級容災(zāi)的能力。

?2?  只有2個城市有機房的條件下，希望能夠具備城市級容災(zāi)的能力。

此時，分布式多副本數(shù)據(jù)一致性協(xié)議便無法滿足需求，比如前面提到過的：“同城2機房3副本”的方案無法抵御機房級災(zāi)難，“2地3機房5副本”的方案無法抵御城市級災(zāi)難。而采用傳統(tǒng)數(shù)據(jù)庫的“主從復(fù)制”模式（準確地說，是它的一個變種），則能滿足這類需求。

不過，這種方案的弊端也是很明顯的。首先，和傳統(tǒng)數(shù)據(jù)庫一樣，具有“RPO>0，不能自動切主導(dǎo)致RTO較長”的問題，其次這種部署方式下數(shù)據(jù)的副本數(shù)達到了6個，成本也比較高。

綜合來看，這種模式只適用在“用戶實在無法滿足機房配置要求，但又希望具備機房級容災(zāi)和城市級容災(zāi)能力”的特殊場景下。我們前面提到過，由于歷史原因，不少企業(yè)級用戶恰恰是有這種需求：希望用同城2機房的部署實現(xiàn)機房級容災(zāi)能力，用2地3機房的部署實現(xiàn)城市級容災(zāi)能力。因此，如果用戶能接受此方案的各種弊端（RPO>0，RTO較長，副本數(shù)過多），就可以用這種方案實現(xiàn)高可用及（有損）容災(zāi)能力。

4     總結(jié)

通過前面對幾種方案的詳細闡述，相信大家已經(jīng)對OceanBase及分布式數(shù)據(jù)庫的高可用和容災(zāi)方案有了大致的了解。說來說去，核心思想就是要充分利用分布式多副本數(shù)據(jù)一致性協(xié)議的原理，并結(jié)合各種意外情況的具體特點（個別硬件故障？機房級災(zāi)難？還是城市級災(zāi)難？），找到對應(yīng)的解決之道。如果客戶的基礎(chǔ)設(shè)施條件有限，不能滿足分布式多副本數(shù)據(jù)一致性協(xié)議的部署要求，那么可以考慮引入其它方式，比如集群間數(shù)據(jù)復(fù)制。

下面的表格中，將上面幾種方案做了一個總結(jié)，方便讀者參考：

大體來講，針對不同的具體情況，下面幾種方案都滿足了“RPO=0、低RTO、故障時自動切換”的要求，而且在技術(shù)上沒有明顯的缺陷，應(yīng)該作為高可用及容災(zāi)方案的首選：

?2?  單機房3副本方案

如果沒有任何機房級容災(zāi)或者城市級容災(zāi)的要求，只有最簡單的高可用要求，那么這種簡單易行的部署方案是再好不過了。

?2?  同城3機房3副本方案

如果有機房級容災(zāi)的要求，但沒有城市級容災(zāi)的要求，那么這種方案是最佳選擇。

如果用戶只有同城2機房而沒有建設(shè)第3機房，可以考慮在同城內(nèi)租借一個機房（甚至只租借部分機柜）來滿足3機房的條件，并可以利用OceanBase的“日志副本”技術(shù)降低部署難度。

?2?  3地3機房5副本方案

如果既有機房級容災(zāi)的要求，也有城市級容災(zāi)的要求，那么這種方案能全部滿足，提供最高級別的高可用性。

如果用戶的基礎(chǔ)設(shè)施條件有限，無法滿足上面幾種方案的要求，但同時又要求機房級容災(zāi)能力或者城市級容災(zāi)能力，應(yīng)考慮“集群間數(shù)據(jù)復(fù)制”方案。

最后，也必須意識到技術(shù)在不斷進步，OceanBase在不斷進步，用戶的IT建設(shè)也在不斷進步。今天的最佳方案也許明天就能找到更好的替代者，因此我們必須以發(fā)展的眼光持續(xù)進化我們的技術(shù)方案，才能讓OceanBase的用戶在未來有更多更好的選擇。在這個過程中，我們也非常希望和業(yè)界的朋友及廣大用戶有更多的技術(shù)交流和思想碰撞，共同推進分布式數(shù)據(jù)庫技術(shù)下高可用及容災(zāi)方案的發(fā)展。