概述 - PolarDB - 阿里雲

PolarDB-X高可用架構滿足RPO=0，本文介紹PolarDB-X實現高可用的技術原理。

技術原理

PolarDB-X採用資料多副本架構（比如三副本、五副本），為了保證副本間的強一致性（RPO=0），採用Paxos的多數派複製協議，每次寫入都要獲得超過半數節點的確認，即便其中1個節點宕機，叢集也仍然能正常提供服務。Paxos演算法能夠保證副本間的強一致性，徹底解決副本不一致問題。

在PolarDB-X中，資料副本基於資料狀態機器的狀態劃分為兩類：普通型（Normal）和日誌型（Logger）。進一步地，根據是否參與投票選舉，複製組中的副本可細分為以下角色：

副本角色	角色類型	角色說明
Leader	Normal	領導者，負責處理用戶端的請求並進行決策，Leader需要維護日誌，以保證資料的一致性和可恢複性。
Follower	Normal	跟隨者，接受Leader的指令並進行執行，當Leader宕機或無法被訪問時可以通過競選成為新的Leader。
Logger	Logger	日誌者，與Follower角色類似，僅提供多數派協議服務，但不提供資料服務。當Leader宕機或無法被訪問時，會參與Leader的競選投票，短時間內有可能會被選舉為Leader，但不會提供資料服務，等待其餘多數派Follower角色完成協議日誌追平後，Logger會主動讓出Leader。
Learner	Normal	學習者，只能被動接收系統狀態資訊，不能參與投票和決策，可以避免對系統的影響。

主執行個體 DN：由2個資料副本（Normal）+ 1個日誌型副本（Logger）組成。其中日誌副本Logger因只儲存日誌，不需要儲存資料，資源佔用非常小，因此，這種三副本的配置能夠在成本上接近傳統的主備兩副本方案。
唯讀執行個體 DN：採用1個資料副本，基於Learner角色非同步同步主執行個體的資料，其本身並不參與Paxos協議的投票和決策，因此唯讀執行個體出現異常不會影響主執行個體，可以滿足唯讀執行個體故障隔離的要求。

PolarDB-X針對主執行個體DN，基於Paxos多副本，提供了多種容災形態：

部署模式	副本策略	容災能力
單可用性區域	三副本（2個資料副本 + 1個日誌副本）	能夠防範少數派1個節點的故障。無法防範機房級故障。
三可用性區域	三副本（2個資料副本 + 1個日誌副本）	能夠防範少數派1個節點故障。能夠防範單機房故障。無法防範城市級故障。
兩地三中心	五副本（5個資料副本）	能夠防範少數派2個節點故障。能夠防範單機房故障。能夠防範城市級的故障。

PolarDB-X針對唯讀執行個體 DN，結合主執行個體DN的不同容災形態適配：

主執行個體部署模式	唯讀執行個體副本策略
單可用性區域	一副本，需對齊主執行個體的地區，可用性區域選擇可以不同。
三可用性區域	一副本，需對齊主執行個體的地區，可用性區域選擇可以不同。
兩地三中心	一副本，需對齊主執行個體的中心地區，可用性區域選擇可以不同。

高可用樣本：