PolarDB：兩地三中心

權重化選舉

PolarDB-X在兩地三中心設計中引入選舉權重，對應的工作原理：

• 樂觀權重機制：在Paxos多數派共識協議的選舉策略中，那些更容易發起選舉的節點傾向於成為Leader。為了最佳化這一點，通過引入權重概念，對不同節點設定了啟動Leader選舉的隨機延時，從而保證那些擁有較高權重的節點能夠優先發起Leader選舉。

• 強制權重機制：當某一個新成為Leader的節點發現自己不是所有節點中權重最高的節點的時候（當所有節點權重一致的時候，任意節點都是權重最高的點，所以此判定不生效），不會立刻放開寫入，而是繼續等待一個選舉逾時的時間段（稱為禪讓階段），在禪讓階段會每隔一個心跳時間（比如1~2秒），向其它節點發送一次心跳探測。在選舉時間段結束以後，如果收到其他權重比自己大的節點回包，即向回包節點中權重最大的節點發起一次Leader轉移，確保高權重的節點成為Leader。

PolarDB-X兩地三中心副本的選舉權重配置：

當中心機房1的Leader副本出現故障，觸發Leader選舉，同機房下的Follower副本選舉權重為7，優先會成為Leader，滿足同機房優先的策略。

副本數動態調整

在兩地三中心中，5副本多數派的複製組需要>=3個副本完成同步響應，預設情況下主中心的4副本會因為網路延遲的優勢，優先在同城完成多數派的同步響應，多數派協議的延遲基本在1ms左右。但出現中心機房層級的故障後僅剩餘3副本，會導致必須等待備份中心的副本也同步響應，從而導致多數派協議的延遲增加30ms（例如，常見的金融行業中主中心和備份中心的網路延遲在30ms左右）。

常見的副本數調整情境：

• 5副本降級為3副本，引入downgrade_follower指令將Follower角色降級Learner角色，動態修改兩個副本的角色

• 3副本升級為5副本，引入upgrade_learner指令將Learner角色升級為Follower角色，需要確保Learner非同步複製日誌追平。

• 1副本升級為3副本，引入add_follower指令動態新增節點，新節點會先成為Learner角色，追平日誌之後自動轉成Follower角色。

單副本強制啟動

兩地三中心中，當中心地區完全故障時，常見的多數派共識協議會因為剩餘1個副本無法滿足多數派，導致備份中心的副本無法承擔資料服務。

PolarDB-X支援單副本強制啟動的能力，引入force_single_mode指令，強制單節點服務並剔除所有Follower。另外，等中心機房故障恢複後，通過副本數動態調整能力，再從1副本恢複為3副本、5副本，實現最終的資料服務的恢複。

異地備叢集

金融行業容災標準，針對異地容災的RPO和RTO都有細粒度的要求，如下表所示：

PolarDB-X為滿足異地容災 RTO 的要求，採用兩地三中心 5 副本 + 主備叢集提供異地備叢集執行個體，當中心地區完全故障時，業務可以快速切流到異地備叢集來實現故障恢複。

兩地三中心主備叢集相關的設計要點：

• PolarDB-X的主叢集，採用跨地區Paxos複製協議，需要>=3個副本完成同步響應，預設情況主中心的4副本會因為網路延遲的優勢，優先在同城完成多數派的同步響應，而主叢集的異地副本普遍是非同步響應，所以主叢集不會受到異地副本的網路延遲影響。

• PolarDB-X的備叢集，主要部署在異地，通過PolarDB-X的CDC日誌節點群組件，構建准即時的跨叢集主備複製，雖然異地備叢集會有一定的資料複寫延遲，但需要確保分散式交易情境下的原子性複製，避免出現事務不一致的情況。

• 跨叢集的主備複製，尤其在兩地三中心情境（主叢集的異地副本，不同Paxos複製組會因為網路延遲出現分散式交易複製進度之間有差異），需要在異地部署CDC日誌節點進行分散式交易排序重組，提供分散式交易的原子性複製能力，確保跨叢集主備複製不會出現事務只有一半提交的狀態。通過原子性事務複製，在日常的容災演練、以及真實故障情境下，都可以確保業務切流到異地備叢集時交易資料的完整性。

建立執行個體

在購買PolarDB-X執行個體時，部署方式可以選擇兩地三中心。

查看執行個體拓撲

在執行個體基本資料頁面底部的拓撲資訊地區，可以查看對應資源的可用性區域資訊。

容災切換

1. 登入PolarDB分布式版控制台。

2. 在頁面左上方選擇目標執行個體所在地區。

3. 在執行個體列表頁，單擊PolarDB-X 2.0頁簽。

4. 找到目標執行個體，單擊執行個體ID。

5. 在基本資料頁面底部的拓撲資訊地區，單擊右側的指定主可用性區域。

   

6. 在彈出的指定主可用性區域對話方塊，選擇機房、主可用性區域、切換模式。

   

7. 單擊確認。