OceanBase資料庫高可用及容災方案詳細介紹

OceanBase 資料庫高可用及容災方案詳細介紹

1 前言

眾所周知，作為生產系統中極為關鍵的核心軟體，資料庫產品的高可用性一直是使用者極為關注的功能點。尤其是在金融這樣一個特殊的領域裡，無論是從監管的要求來看，還是從業務需求本身來看，都需要提供24*7持續不間斷的服務，這就對金融行業中資料庫產品的高可用性提出了很高的要求，不但需要應對個別硬體故障的情況，還必須能夠應對機房整體故障和城市災難等極端情況，保證資料庫在各種意外情況下都能持續提供服務，即具備機房級容災能力和城市級容災能力。本文的主要目的，是總結和回顧一下傳統資料庫產品常用的高可用及容災方案，並向讀者介紹一下以OceanBase為代表的分散式資料庫常用的方案，希望能夠起到拋磚引玉的作用，引發讀者關於新型分散式架構下高可用及容災方案的思考。

2 背景介紹

首先，我們回顧一下傳統的關係型資料庫產品（如Oracle、DB2等）常用的高可用及容災技術。我們知道，傳統資料庫產品最初都是單點架構，並不具備高可用設計，更多的是基於高階硬體產品滿足“硬體可靠”的假設。隨著時間的推移，傳統資料庫產品先後推出了採用“主從複製”架構的高可用方案，比如Oracle的Data Guard技術和DB2的HADR技術，其主要思路是：在原有的單資料庫節點（主節點）之外再增加一個對等的資料庫節點（從節點），通過資料庫層面的複製技術（通常是日誌複製）將主節點產生的資料實時複製到從節點；正常情況下從節點不提供對外服務，當主節點發生故障時，在從節點上執行“切主”動作將從節點變成主節點，繼續提供服務。在主從節點的部署方式上，除了本地單機房部署外，往往也支援同城災備部署和異地災備部署，因此也就具備了機房級容災和城市級容災的能力。很多新興的資料庫產品（如MySQL）也是採用“主從複製”模式來實現高可用及容災特性。

除了資料庫層面的主從複製技術之外，還有一些在底層硬體上實現的高可用方案，比如在主機層面用HACMP技術以應對主機故障，或者在儲存層面採取複製技術（比如FlashCopy）來提供資料冗餘等。這些技術雖然也可以用來實現高可用和容災能力，但和應用的整合度不高，會使災難切換方案變得很複雜，並且會有相對較長的故障恢復時間（RTO），所以通常不是資料庫使用者的首選。

最後，近些年還出現了一些支援異種資料庫之間相互複製資料的產品，比如IBM CDC和Oracle Golden Gate（OGG）。這些產品的特點是比較靈活，可以支援異種資料庫之間的資料複製，也可以指定只複製資料庫中的部分物件（比如只複製指定幾張資料表的資料）。但這些產品的缺點也很明顯：首先相對於資料庫主從複製來說時延偏大，通常會達到秒級以上，而且往往做不到資料庫層面100%的完全複製。因此，這種方式通常作為不同資料庫產品之間做資料“準”實時同步的手段，而不會作為資料庫產品實現高可用及容災的手段。

稍微總結一下，傳統的資料庫產品通常會採用下面的方法實現高可用：

²   在主機層面實施高可用（HACMP）架構，以應對主機故障所帶來的影響（非首選方案）。

²   在儲存層面採用資料複製技術（比如FlashCopy）來提供資料冗餘，以應對儲存損壞所帶來的影響（非首選方案）。

²   在資料庫層面提供 “主從複製” 技術（ 首選方案 ）。

²   第三方資料複製產品，如CDC、OGG等（很少採用）。

通過上述的各種技術，尤其是資料庫“主從複製”技術，使得意外發生時資料庫可以在一定時間內恢復服務，並且大部分資料不會丟失，具備了一定的高可用及容災能力。但是，上面這些技術也有一些難以克服的缺點，以“主從複製”技術為例，雖然它是傳統資料庫裡最先進也是最常用的高可用及容災技術，但還是有一些無法解決的問題：

²   通常情況下無法做到RPO=0，即主節點發生故障或者災難時有交易資料的損失。

可能有的讀者會說：你說錯了！主從複製技術也能實現RPO=0。

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

²   RTO 相對較大，通常以十分鐘甚至小時為計算單位，會給業務帶來比較大的損失。

造成這一情況的根本原因，是“主從複製”模式下從節點不具備自動切主的能力。

由於“主從複製“模式中缺少第三方仲裁者的角色，當主從節點之間的心跳訊號異常時，從節點無法靠自己判斷到底是主點故障了，還是主從之間的網路故障了。此時，如果從節點認為是主節點故障而將自己自動切換成主節點，就極容易導致“雙主”、“腦裂”（brain-split）的局面，對使用者來說這是絕對無法接受的結果。所以資料庫“主從複製”技術從來不會提供“從節點自動切換為主節點”的功能，一定要由“人”來確認主節點確實故障了，並手工發起從節點的切主動作，這就大大增加了系統恢復的時間（RTO）。

聊完了傳統資料庫的高可用技術，我們再來看看另一種逐漸被越來越多的技術廠商所採用的技術，那就是分散式多副本資料一致性技術，通常是基於Paxos協議或者Raft協議來實現。這種技術會將資料儲存在多份副本上，每一次對資料的修改操作都會強同步到多數派副本上，在保證了資料冗餘的同時，不再像“主從複製”技術那樣依賴某個資料節點的穩定性，從而消除了傳統主從複製技術下從節點給主節點帶來的風險。同時，在主節點故障的情況下，其餘節點會自動選舉出新的主節點以實現高可用（個別從節點故障則完全不影響服務），整個過程非常快速且完全無需人工干預。因此，這種技術不僅能保證RPO=0，而且大大減小了RTO，相比傳統“主從複製”技術來說可以提供更強大的高可用能力。

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

3 OceanBase常用的高可用及容災方案

資料庫從誕生之初，就利用Paxos協議在底層實現了多副本資料一致性，具有上述 RPO=0 、低RTO（通常在30s以下）、故障時自動切換 ” 的優勢。而經過多年實際應用場景的歷練後，尤其是像支付寶、淘寶、網商銀行這種高併發、高訪問量、24*7持續交易場景的磨練，OceanBase資料庫已經摸索出一套完整的、經過實踐檢驗的高可用及容災方案。下面我們就結合OceanBase資料庫的實踐經驗，向大家介紹一下分散式資料常用的一些高可用及容災方案。

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

²   OBServer

一個OBServer指的是一個獨立提供服務（share-nothing）的OceanBase資料庫節點，這是一個軟體層面的定義。但通常一臺物理伺服器上只有一個OBServer，因此也可以認為一個OBServer等同於OceanBase資料庫叢集的一個物理節點。

²   Zone

這是OceanBase資料庫的一個內部概念。一個Zone是一個或者一些OBServer組成的邏輯集合，一個Zone裡的所有OBServer都在一個機房內。

從分散式多副本資料一致性協議的角度來看，可以認為一個Zone就是OceanBase資料庫叢集的一個“副本”，如果是三副本架構那就會有三個Zone。

²   IDC

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

1.1 單機房3副本

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

這種方案具備一定程度的高可用 能力，可抵禦個別硬體故障，比如在個別伺服器宕機、個別硬碟損壞等情況下，資料庫叢集還能持續提供服務。 此外，這種方案具有部署方便，成本低的特點，只要有一個機房，機房內有足夠多的聯網機器，就可以部署了。

但這種方案也有一個非常明顯的劣勢： 不具備容災能力。如果發生機房級災難或者城市級災難，首先會導致交易停止，而極端情況下（比如機房所有機器損毀）甚至會導致資料丟失。

綜合來看，這種方案雖然部署方便，也具備高可用特性，但其容災的能力卻是最低的，對於具有容災要求的系統來說顯然是不適合的。如果使用者的硬體條件有限，只能提供一個機房，並且使用者對系統的容災能力沒有要求，那麼這種方案是一個非常合適的選擇。

由於分散式多副本資料一致性協議要將每一個事務的資料強同步到多數派副本中，這種部署模式下必然導致頻繁的跨機房同步操作。為了保證資料庫的寫效能，對機房之間的網路質量有比較高的要求，通常要求任何兩個機房之間的網路時延不超過2毫秒（ms）。

（P.S. 後面所有關於“同城機房”的描述中，預設都有類似的網路要求，後文就不再贅述了）

相對於“單機房3副本”來說，這種方案的優勢是很明顯的： 除了可以抵禦個別硬體故障，還可以抵禦機房級災難：任何一個機房遇到災難，都不會導致交易停止或者資料丟失。

不過，並不是每一個使用者都能夠提供“同城三機房”的部署條件。即使是高階企業級使用者，往往也只具備同城2機房（主機房+同城災備機房）的條件，因此3機房對使用者的基礎設施來說提出了一定的挑戰，也增加了使用者的部署成本。如果考慮到上面說的任意2個機房之間都要做到“網路低延時”，那成本會進一步增加。因此，在考慮這種部署方案時，要事先和使用者做好充分的溝通，確保使用者能提供符合要求的基礎設施。最後還要指出的一點就是，這種方案仍然不具備城市級容災的能力，如果發生城市級災難，還是會導致交易停止，甚至有資料丟失的風險。

綜合來看，如果使用者能夠提供同城3機房的硬體設施，並且沒有城市級容災的要求，那麼推薦使用這種方案，可以在城市內提供非常好的高可用及容災能力。事實上，OceanBase資料庫的一些外部企業級客戶就是採用了這種部署方式，收到了很好的效果。

如果使用者暫時只具備同城2機房的條件，那麼可以考慮在城市內租借一個機房以滿足“同城3機房”的條件，其成本相對於建設一個全新IDC來說還是低了很多。甚至可以只為個別資料庫叢集租借一個同城機房內的部分機櫃，這樣就進一步降低了成本，對企業級使用者來說這個成本應該還是在可接受範圍內的。

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

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

2 ）第3個城市和前兩個城市的距離相對較遠（比如深圳），它和前2個城市之間的網路時延應保證在30毫秒（ms）內。這個城市的機房內部署1個Zone（副本）。

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

不過，這種方案雖然能夠提供全面的資料安全性保護，在實際部署中也會面臨一些問題和挑戰。首先，需要在3個城市內各有一個機房，3個城市之間要滿足“2近1遠”，而且相互之間的網路時延也要滿足一定條件（詳見前文描述），可以說這對使用者的基礎設施條件提出了非常大的挑戰，即使對高階企業級使用者來說，也很難滿足這個條件，最多隻具備2地3機房的條件。另外，5副本相對於3副本來說增加了2個副本，進一步提高了硬體成本，也加大了這個方案的難度。

在實際應用中，如果使用者對SLA提出了最高要求，需要抵禦機房級災難和城市級災難，並且希望做到 “RPO=0、低RTO、故障時自動切換” ，那麼此方案將是不二之選。事實上，網商銀行的資料庫叢集部署就是採用這種架構，支付寶中的部分核心資料也是採用了這種架構，它們為業務提供了最佳的資料安全性保障。

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

前面介紹過，如果只需滿足機房級容災的要求，那麼可以考慮 的方案，以抵禦個別硬體故障和機房級災難。但由於歷史原因，很多企業使用者都建設了“同城2機房（主機房+同城災備機房）”的基礎設施，卻很少有使用者具備“同城3機房”的條件。此時雖然可以租用一個同城機房來滿足3機房條件，但如果使用者真的找不到合適的第3機房，是否就不能在2機房中部署OceanBase資料庫叢集了呢？

其實，這種情況下還是可以利用2機房來完成部署的，只要在主機房中部署2個Zone，同城災備機房中部署1個Zone，就構成了一個跨機房部署的資料庫叢集。

但如果主機房發生機房級災難，那麼整個資料庫叢集只剩下同城災備機房的1個Zone， 不再滿足多數派條件，無法繼續提供服務 。因此這種方案是不能抵禦機房級災難的 ，只是在同城災備機房中保留了一份資料，以後可以將資料恢復出來（但RPO>0，資料會有少量丟失），避免了資料全部丟失的情況。

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

前面介紹過， “3地3機房5副本”的方案 可以提供最高級別的高可用性，可以抵禦個別硬體故障、機房級災難和城市級災難等各種情況。但我們同時也提到了，傳統企業使用者很少能滿足“3地3機房”的要求，很多企業使用者只具備 “2地3機房（主機房+同城災備機房+異地災備機房）” 的條件。那麼這種情況下，分散式資料庫是否能利用“2地3機房”完成部署呢？

事實上，這種情況下OceanBase也可以完成資料庫叢集的部署，只要在主機房和同城災備機房中各部署2個Zone，在異地災備機房中部署1個Zone，就構成了一個跨機房部署的資料庫叢集。

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

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

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

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

最後，如果使用者實在無法找到第3個城市來部署機房，但同時可以接受“發生城市級災難時RPO>0”的代價，那麼可以在兩個城市之間採取“叢集間資料複製”的方法（後文有詳細的介紹）。這種方式的弊端很明顯，遇到城市級災難時會有“RPO>0，不能自動切主導致RTO較長”的問題，但它可以利用2個城市實現城市級（有損）容災，減小了部署的難度。如果採用此方案的話，“主”城市應該採用“同城3機房3副本”的架構，以提供機房級容災的能力。

這種方案類似傳統資料庫的“主從複製”方案，通過資料複製軟體 將一個OceanBase資料庫叢集 的資料複製到另一個（或者多個）OceanBase資料庫叢集，以應對單個OceanBase資料庫叢集的故障。通常來說，不同的OceanBase資料庫叢集會部署在不同的IDC中，以應對機房級災難和城市級災難。

這種方式主要是為了應對以下幾種情況：

²   只有2個城市有機房的條件下，希望能夠具備城市級容災的能力。

此時，分散式多副本資料一致性協議便無法滿足需求，比如前面提到過的：“同城2機房3副本”的方案無法抵禦機房級災難，“2地3機房5副本”的方案無法抵禦城市級災難。而採用傳統資料庫的“主從複製”模式（準確地說，是它的一個變種），則能滿足這類需求。

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

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

4 總結

通過前面對幾種方案的詳細闡述，相信大家已經對OceanBase及分散式資料庫的高可用和容災方案有了大致的瞭解。說來說去，核心思想就是要充分利用 分散式多副本資料一致性協議的 原理，並結合各種意外情況的具體特點（個別硬體故障？機房級災難？還是城市級災難？），找到對應的解決之道。如果客戶的基礎設施條件有限，不能滿足分散式多副本資料一致性協議的部署要求，那麼可以考慮引入其它方式，比如叢集間資料複製。

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

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

²   單機房3副本方案

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

²   同城3機房3副本方案

如果使用者只有同城2機房而沒有建設第3機房，可以考慮在同城內租借一個機房（甚至只租借部分機櫃）來滿足3機房的條件，並可以利用OceanBase的“日誌副本”技術降低部署難度。

²   3 地3機房5副本方案

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

如果使用者的基礎設施條件有限，無法滿足上面幾種方案的要求，但同時又要求機房級容災能力或者城市級容災能力，應考慮“叢集間資料複製”方案。

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