權重化選舉

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. 單擊確認。