[TOC] # 高可用方案 OceanBase 數據庫提供高可用能力，提升系統的可靠性。OceanBase 數據庫的高可用在設計時主要考慮兩個方面： * 當 OceanBase 數據庫的節點發生宕機或意外中斷等故障時，能夠自動恢復數據庫的可用性，減少業務受影響時間，避免業務因為數據庫節點故障而中斷。 * 在 OceanBase 數據庫少數節點發生故障導致這部分節點的數據無法讀取時，保證業務數據不會丟失。 不同于傳統數據庫的主備或一主多從方案，OceanBase 數據庫使用性價比較高、可靠性略低的服務器，同一數據保存在多臺（>= 3）服務器中的半數以上服務器上（例如 3 臺中的 2 臺，5 臺中的 3 臺等），每一筆寫事務必須到達半數以上服務器才生效，因此當少數服務器故障時不會有任何數據丟失。  不僅如此，傳統數據庫主備鏡像在主庫發生故障時，通常需要外部工具或人工把備庫升級成主庫，而 OceanBase 數據庫底層實現了 Paxos 高可用協議，在主庫故障后，剩余的服務器會很快自動選舉出新的主庫，并繼續提供服務。 ## 分布式選舉 OceanBase 數據庫以分區為單位組建 Paxos 協議組。每個分區都有多份副本，通過維護成員組關系，自動建立 Paxos 組。同時在以分區為單位的 Paxos 協議組的基礎上，自動選舉主副本。 Paxos 協議組中的每個副本在正常工作時分為兩種不同的角色： * **Leader：**表示主副本，數據庫服務的強一致性讀以及寫服務均是由 Leader 提供的，在此基礎上提供分布式事務等多方面的能力。 * **Follower：**表示從副本，為 Leader 同步的數據進行投票，并提供弱一致性讀服務。 分布式選舉協議通過 Leader 周期性下發的 Lease 機制來維護自身角色的權威性。在系統出現故障（既包括 Leader 副本所在的機器故障，也包括 Leader 與多數派之間出現網絡故障）時，Leader 和 Follower 上記錄的 Lease 均會過期。過期后，所有聯通的 Follower 副本會自行選舉一個新的 Leader 提供讀寫服務。 分布式選舉協議支持對 Leader 角色進行切換。切換 Leader 的操作既可以是總控節點（RootService）發起，也可以由用戶通過 alter system 命令發起。 選舉協議支持豐富的選舉優先級，無主選舉和 Leader 切換時考慮的選舉優先級如下： 1. 成員組的版本號。 2. 所在副本同步日志的完整程度。 3. locality 中設置的 primary region 信息。 4. 所在副本的一些基礎情況（如是否被判定磁盤故障等）。 ## 多副本日志同步 Paxos 組成員通過 Redo Log 的多數派強同步來確保數據的持久化。 當一個分區的 Leader 有日志需要提交時，會首先將待提交日志拷貝到本機內存的 Buffer 之中，同時將這部分日志異步的發給多個 Follower。 拷貝到本機 Buffer 的日志會由后臺的寫盤線程完成落盤操作，并在此之后標記落盤完成。同步給 Follower 的日志會在落盤完成后，給 Leader 回復確認消息。 Leader 只需要收到包括自己在內的多數派的落盤完成消息后，即認為此日志已經完成了強同步，而無需等待其他 Follower 副本的反饋，此時即會向上層返回提交成功。 如果有 Follower 副本出現故障導致缺失了部分日志，這個 Follower 會在故障恢復后，自動從 Leader 副本上補齊所缺失的日志，整個流程是完全自動的。 整個日志提交流程僅需要多數派在線。 ## 多日志流系統 如上所述，每個分區是一個獨立的 Paxos 組，每個 Paxos 組是一個獨立的日志流。 在一個 Paxos 組內部，每個 Paxos 實例對應于一條日志，每條日志在組內有一個唯一的編號，稱作 LogID，每個組內的 LogID 均從 1 開始編號，這樣的一組日志構成了一個日志流。 每個 observer 進程服務于多個分區，多個分區一同構成了一個多日志流系統。 為了減少磁盤寫入的開銷，多個日志流會寫到相同的日志文件之中。 ## 節點故障的處理策略 一臺 observer 出現節點故障后，系統會根據參數 server\_permanent\_offline\_time（默認值 3600s）設置的值來進行相應的操作。 如果故障時間小于該參數設置的值，由于節點故障時間較短，認為此進程有可能較快恢復，因此 OceanBase 數據庫暫時不做處理，以避免頻繁的數據遷移。 如果故障時間大于等于該參數設置的值，OceanBase 數據庫會將此機器標記為永久下線。此時會為故障節點上所保存的所有分區進行補副本操作。所補副本仍滿足對應租戶的 locality 約束。