資料庫高可用面臨的挑戰與解決之道｜OceanBaseDev

OceanBase資料庫發表於2020-11-27
資料庫dev

本文根據 OceanBaseDev Meetup#1 上海站分享整理，本次活動針對分散式資料庫的分散式事務以及落地實踐展開具體分享。

本文作者：羨林，螞蟻集團高階技術專家，2012年畢業於北京郵電大學計算機專業。2013年加入 OceanBase 團隊，參與了OceanBase 1.0 及 2.0 版本的設計與開發，目前主要負責 OceanBase 高可用及一致性相關的工作。分享視訊以及 PPT 檢視地址見文末。


本文將首先介紹實現高可用資料庫所面臨的挑戰，然後從幾個方面介紹解決高可用問題所需的分散式一致性技術的相關內容，希望對你有所幫助。


在關聯式資料庫系統之中，事務需要滿足 ACID 特性。其中，"D"表示"永續性"(Durability)，即一旦事務完成，則事務對資料庫的影響就不會丟失。


DBMS 複雜性的一個重要原因就是需要滿足永續性：資料庫中的任何修改直到該修改被儲存到非易失性的輔助儲存器中，才能認為這個修改是最終有效的。


資料是企業的核心命脈，滿足永續性是資料庫系統正確服務的先決條件。在此基礎上，隨著資訊時代的發展，客戶對資料庫系統提出了更高的要求，即服務不能停，要求最基礎的資料庫系統提供高的可用性。


以支付寶為例，支付寶的客戶24小時均會使用支付寶提供的服務，這對整個系統提出了非常高的挑戰。


客觀現實及傳統資料庫的解決方案


如果系統不出現任何故障，那麼同時實現資料的可靠儲存和服務的持續可用也許是簡單的。


但在真實場景中，故障是不可避免的。有多種可能的故障原因：


  • 硬體故障:  磁碟、網路，甚至 CPU 和 Memory 均可能出現故障。以硬體廠商的統計資料為例，硬碟的年故障率達到1.25%, 伺服器的年故障率會更高；
  • 軟體故障：作業系統、檔案系統以及資料庫系統本身，均有可能出現軟體故障；
  • 人為誤操作：運維人員和 DBA 在運維、升級系統時，存在誤操作的可能，每個操作均如履薄冰；
  • 故障範圍：隨著系統規模越來越大，故障可能出現的範圍從單機、機架，到整個機房甚至一個城市；


傳統資料庫一般通過共享儲存或主備同步的方案來應對可能出現的故障。


在共享儲存的方案中，往往依賴於高階硬體來提高可用性，這一方面需要更高的成本，另一方面在共享儲存出現故障時，整個系統仍需要停服務，甚至有丟資料的風險。除此之外，共享儲存不支援跨機房部署，無機房級的容災能力。


在主備同步的方案中，無法平衡服務的可靠性和可用性。主備同步本質上只有兩種選擇：非同步同步和強同步。非同步同步無法保證在主庫故障時資料的可靠性，而強同步無法保證在主庫、備庫或網路三者任一出現故障時系統的可用性。


分散式一致性協議


如上所述，共享儲存和主備同步的方案在故障場景下均無法很好的平衡資料的可靠性和系統的可用性。針對此問題，電腦科學家、圖靈獎獲得者 Leslie Lamport 早在20多年前就提出了對應的解決方案，也就是著名的 Paxos 協議。


我們先來看下 Wiki 裡對分散式一致性協議的說明：


  • Consensus is the process of agreeing on one result among a group of participants.
  • This problem becomes difficult when the participants or their communications may experience failures.


通過 Paxos 協議，使用三副本/五副本，可以很好的平衡資料的可靠性和系統的可用性；在少數派副本出現故障時，Paxos 協議可以確保系統資料不丟，且服務持續可用。


在 Paxos 協議裡，有兩種不同的角色：


  • Proposer: 提案發起者；
  • Acceptor: 提案接受者，對 Proposer 的訊息進行應答；


一個或多個 Proposer 可以發起提案，系統需要對所有提案中的某一個提案達成一致，協議保證最多對一個確定的提案達成一致。


一個基本的 Paxos 流程分 prepare、accept 兩步，如下圖所示：


F2E0CE7A-CFB2-4D62-8032-2FCF9686EF6E.png


Paxos協議的詳細內容參考論文《Paxos Made Simple》。另外，Raft 協議作為 Paxos 協議的一個變種，其論文《In Search of an Understandable Consensus Algorithm (Extended Version)》也值得細讀。


OceanBase 一致性工程實踐


OceanBase 是最早將 Paxos 協議用於關係型資料庫的系統之一。通過資料多副本，OceanBase 用軟體手段在普通 PC 伺服器上實現了金融級的資料高可靠和系統的高可用，實現了 RPO = 0 以及 RTO < 30s。通過提供多種部署模式的選擇，可以分別實現機器級、機房級以及城市級的容災能力。


如下，是 OceanBase 的一個簡化的部署結構圖。圖中每個 ZONE 是一個容災域，每個 OBServer 是一個資料庫服務節點，每個 OBServer 中包含多個Paxos Group 提供服務。


image.png


這一小節分別介紹 OceanBase 使用的 Multi-Paxos 協議，為了節省成本開發的日誌副本功能，以及為了保證資料正確性所做的一系列工作。


Multi-Paxos


在資料庫系統中，實現事務的永續性依賴的是 redo log。使用 Paxos 協議，每一條 redo log 即對應一個 Paxos Instance。


如果使用基本的 Paxos 協議決定一條 redo log 的內容，至少會有兩輪 RPC 延遲。基於此，使用 Multi-Paxos 協議對 redo log 的同步做優化，在系統穩定的情況下，一條 redo log 的同步，僅需要一輪 RPC 延遲。


Multi-Paxos 協議需要有一個穩定的 Leader。OceanBase 通過一個選舉協議在多個副本中選擇一個 Leader，所有的讀寫請求均通過 Leader 進行。寫請求會要求日誌同步到多數派副本後應答客戶端持久化成功，而讀請求僅需要訪問 Leader 即可保證讀取到最新的資料。


Leader 作為 Multi-Paxos 協議的 Proposer。假定 Proposer 比較穩定，可以一次性對所有的 Paxos Instance 做 prepare，所有 Paxos Instance 共用一個 maxPreparedProposalNO。


一輪具體的 Multi-Paxos 流程如下：


  • 選舉協議從所有副本中選擇出一個 Leader 節點，作為 Proposer；
  • Proposer 選擇一個 ProposalID 對所有日誌進行 Prepare； Follower 節點（也是協議中的 Acceptor）收到後進行檢查：
    • 如果未收到過更大 ProposalID 的請求，則接受此 Prepare 訊息，並回復 LocalMaxLogID;
    • 否則直接忽略此請求;
  • Reconfirm: Proposer 收到多數派 Acceptor 對 Prepare 的響應，選取響應中 LocalMaxLogID 最大值，記做 ReconfirmMaxLogID，假設本地最大確認 LogID 為 K，對於 [K+1, ReconfirmMaxLogID] 範圍內所有日誌，通過 Prepare/Accept 兩階段重新執行 Paxos 協議流程;
  • Leader Active: Reconfirm 完成後，切換到此狀態提供資料的讀寫服務；


Multi-Paxos 實現了日誌的亂序同步，對網路抖動的容忍性更好。


B5C41A90-04B8-4EA5-91D4-7645CCEA3F63.png


日誌副本


傳統資料庫的主備同步同一份資料儲存了兩份，而 Paxos 協議作為一個多數派協議，需要至少三副本。我們為了提供高可用能力付出了額外的成本，那這部分成本是否可以減小甚至消除呢?


首先，我們分析一個副本所需的資源型別：CPU、記憶體、磁碟空間。


作為一個備副本而言，CPU 和記憶體主要用於 redo log 的回放，而磁碟空間主要用於儲存使用者資料和 redo log。和使用者資料相比，redo log 所佔用的磁碟空間是非常少的，常常只需要十分之一甚至更少，並且可以重複使用。


基於上述分析，OceanBase 提供了日誌副本功能，這樣的副本不回放 redo log，節省了 CPU 和記憶體的開銷，同時不儲存使用者資料，僅需要很少的磁碟空間用於 Paxos 投票。


在具體部署上，資料庫伺服器可以交叉部署正常副本和日誌副本，也可以採購低配低成本伺服器，僅用於儲存日誌副本。


資料正確性保證


Paxos 協議是分散式資料庫系統的基石，而通過 Paxos 協議實現的多副本資料一致性又是一切資料正確性的前提。


OceanBase 從兩方面來確保資料的正確性。


  1. 異常測試


在測試階段模擬各類異常是確保正確性的基礎。具體工作如下：


  • 設計了專門測試 Paxos 協議流程的測試框架，mock 寫盤和網路，模擬亂序、丟包、延時等多種場景，測試協議正確性；
  • 數十個容災測試用例，測試資料節點遇到各類異常時的行為；
  • 程式碼隨機錯誤注入，模擬記憶體分配失敗、隨機的網路丟包；
  • 多個整合測試環境，7*24 不間斷的做各類容災測試；


  1. 完備的 checksum 校驗


除異常測試外，在系統執行過程中，設計了多個維度的 checksum 校驗，用於實時發現可能的資料正確性問題；


  • 日誌體/完整日誌（日誌頭+日誌體）/單次寫入塊的三個層次的 checksum 校驗，用於發現記憶體寫壞、磁碟靜默錯誤等問題；
  • RPC packet checksum 實時校驗，用於發現可能的網路包的資料問題；
  • 單個日誌流的累積 checksum 校驗，任何一條日誌都會校驗從所在日誌流第一條日誌開始到本日誌結束的所有日誌內容的 checksum 校驗和，用於確保多個副本資料的嚴格一致；


總結


分散式一致性協議是實現原生分散式資料庫的關鍵技術之一。本文首先介紹了實現高可用資料庫所面臨的挑戰，然後從幾個方面介紹瞭解決高可用問題所需的分散式一致性技術的相關內容。原生分散式是資料庫的未來，在走向未來的過程中，一定有更多有意思的挑戰，還有非常多的技術難題和挑戰等著我們，歡迎感興趣的小夥伴加入我們！ （歡迎傳送簡歷到 OceanBase-Public@list.alibaba-inc.com ）


回顧資料



來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69909943/viewspace-2737637/，如需轉載，請註明出處，否則將追究法律責任。

相關文章