簡介：在3月2日的阿里云開源 PolarDB 企業級架構發布會上，阿里云數據庫技術專家孟勃榮 帶來了主題為《PolarDB 三節點高可用》的精彩演講。三節點高可用功能主要為 PolarDB 提供金融級強一致性、高可靠性的跨機房復制能力，基于分布式共識算法同步數據庫物理日志，自動failover，任意節點故障后數據零丟失。本議題主要介紹PolarDB三節點高可用的功能特性和關鍵技術。

在3月2日的阿里云開源 PolarDB 企業級架構發布會上，阿里云數據庫技術專家孟勃榮
帶來了主題為《PolarDB 三節點高可用》的精彩演講。三節點高可用功能主要為 PolarDB 提供金融級強一致性、高可靠性的跨機房復制能力，基于分布式共識算法同步數據庫物理日志，自動failover，任意節點故障后數據零丟失。本議題主要介紹PolarDB三節點高可用的功能特性和關鍵技術。

直播回顧視頻：開源PolarDB企業級架構重磅發布-阿里云
PDF下載：?文件下載-阿里云開發者社區

以下根據發布會演講視頻內容整理：

PolarDB for PostgreSQL三節點高可用功能主要是將物理復制與一致性協議相結合，為PolarDB 提供金融級強一致性以及高可靠的跨機房復制能力。

PG 原生的流復制支持異步/同步/Quorum三種同步方式。

同步復制的主要目標是保證數據不丟失，但它同時也會帶來三個問題：

① 無法滿足可用性的要求，備庫出現故障或網絡鏈路抖動的時候，會影響主庫的可用性，這對生產環境是不可接受的。其次它不能完全保證數據不丟失，同步復制保證數據不丟失的方案是當備機沒有完全持久化RW日志前，主庫的事務不能提交。在某種極端情況下，比如主庫已經寫入了WAL日志，等待備庫同步WAL日志的過程中主庫發生了重啟，那么在重啟的過程中，日志回放的過程是不等待備庫持久化的。所以回放完成后，有可能備庫沒有持久化，而日志在主庫上回放完之后已經對外可見了。

② 不具備故障自動切換的能力。自動切換、可用性探測等能力都依賴于外部的組件。

③ 舊的主庫在故障恢復之后，可能無法直接加入到集群。比如當事務在主庫上的WAL日志已經持久化，而備庫還未收到日志或者還未持久化。此時如果主庫出現了故障，備庫切換成主庫后，舊的主庫重新運行后，因為在重啟之前有多余的 WAL 日志，所以無法直接從主庫上拉取日志，必須依賴于其他工具對其一致性進行處理后才能加入到集群里。

異步復制相比于同步復制，性能比較好，可用性也更高，因為備機的故障或網絡鏈路的抖動不會影響主庫，但它最大的問題是丟數據。比如原來在主庫上能看到的數據，發生切換之后在備庫上不存在。其次，它也不具備自動故障切換和自動探測的能力，切換后的主庫無法自動加入到集群里。

Quorum復制使用了多數派的方案之后，可能也能保證不丟數據，但它并沒有涉及到當主機發生故障時如何選取新的主機；其次，每個節點的日志不一致時，如何確保日志的一致性；第三，集群發生變更的時候，如何保證集群狀態最終的一致性。針對以上問題，Quorum復制沒有提供完整的解決方案。所以本質上來說， PG 的 Quorum 復制并不是一個完整的、不丟數據的高可用方案。

我們的方案是將阿里內部的一致性協議 X-Paxos 引入進來協調物理復制。X-Paxos 在阿里內部和阿里云的多個產品上已經穩定運行了很長時間，因此它的穩定性得以保障。它的的一致性協議的算法和其他的協議是類似的。

整個高可用方案是一個單點寫入、多點可讀的集群系統。 Leader 節點作為單點寫入節點對外提供讀寫服務，產生了WAL日志后向其他節點同步。Follower 主要是接受來自于 Leader 節點的 WAL 日志，并進行回放，對外提供只讀服務。

那么它的主要能力是包括以下三個方面：

保證集群內數據的強一致性，即 RPO=0。當多數派節點的WAL日志寫入成功后，才認為此日志在集群層面已經提交成功。發生故障時，其他Follower 節點會自動與 Leader 節點對齊日志。

自動 failover 。在高可用集群中，只要半數以上的節點存活，就能保證集群正常對外提供服務。因此當少數 failover 故障或少數節點網絡不通的時候，并不會影響集群的服務能力。

當 Leader 節點故障或與多數派節點網絡不通的時候，會自動觸發集群重新選主流程，由新主對外提供讀寫服務。另外 Follower 節點也會自動從新的 Leader 節點上同步WAL日志，并且自動與新的 Leader 日志對齊。此時如果Follower 上的日志比新 Leader 上多，則會自動從新 Leader 上對齊WAL日志。

在線集群變更可以支持在線增刪節點、手動切換、角色變換，比如從 Leader 切到 follower角色。此外還能支持所有節點設置選舉權重，選舉權重高的節點會優先被選為主。同時，集群變更操作不影響業務的正常運行，此能力的實現由一致性協議來保證。最終集群內配置達成一致，不會因為集群配置過程中的異常情況導致狀態不一致的問題。

三節點高可用功能中增加了一個新的角色： Learner 節點。它沒有多數派的決策權，但能夠提供只讀服務。

Learner 節點的日志同步狀態與 Leader 無關，也不會影響 Leader ，它的主要作用有兩點：

① 作為加節點的中間狀態。比如新加的 Leader 節點延遲比較大，如果直接將其加入到多數派里，會影響多數派的提交。因此，先以 learner 的角色加入到集群來同步數據，當它的數據基本追上 Leader 之后，再升為 follower節點。

② 作為異地災備節點。它不會影響主庫的可用性，發生 Leader 切換之后，它能自動從新的賬號同步日志，不需要外部的介入。

在集群部署方面，能夠支持跨機房和跨域的部署，包括同機房三副本、同城三機房三副本，以及兩地三機房五副本、三地三機房五副本等。另外跨域也可以利用 Learner 節點進行災備，不會影響 Leader 節點的可用性。

此外，它兼容了 PG 原生的流復制和邏輯復制，能夠保證下游的消費不受影響，保證下游不會出現未提交的數據。

從前文的介紹中可以看到，在 PolarDB 的高可用方案中，至少要存儲三份數據，存儲成本會有所增加。針對這個問題，我們提供了兩個方面的解決方案：

首先，提高資源的利用率。 Follower 節點可以作為只讀節點來提供讀服務，從而增加整個集群的讀擴展能力；此外，支持跨節點的并行查詢能力，可以充分利用各個基節點的資源。

其次，引入了日志節點，減少資源的占用。日志節點本身不存儲數據，它只存儲實時的WAL 日志，僅作為日志持久化的多數派節點之一。此日志節點本身也具備完整的日志復制能力，可以兼容原生的流復制和邏輯復制，可以將其作為下游日志消費的源，從而減少 Leader 節點的日志傳輸壓力?？梢愿鶕掠稳罩鞠M的需求，來定制日志節點的網絡規格或者其他資源。

一致性協議復制的基本原理主要包含三個方面：

① 通過原生的異步流復制來傳輸或同步WAL日志。

② 由一致性協議來推動集群的提交位點。

③ 針對自動 failover 的問題，根據一致性協議層面自身狀態的變化，來驅動數據庫層面的狀態變化。比如心跳超時之后，可能會自動降級。

具體實現上，以 Consensus Log 為載體來推進提交位點。針對每一段WAL日志生成相應的 Consensus Log Entry ，里面記錄了WAL日志的結束 LSN。 而后引入一個持久化依賴，保證每個 Log Entry持久化的時候，本節點上相應位點的WAL日志已經持久化成功。

引入上述兩個機制后，如果一致性協議層面認為 Consensus Log 已經提交成功，則意味著 Consensus Log 已經在多數派上持久化成功，相應位點的WAL日志肯定也已經持久化成功。

以上圖為例， Leader 上已經持久化了三段 WAL 日志，在 Follower 1 節點上，雖然 log entry 的 WAL 日志已經持久化成功，但它對應的 Consensus Log還未持久化成功，所以一致性協議就認為此 Consensus Log也沒有持久化成功。Follower 2 上 Log Entry和Consensus Log 沒有持久化，它的WAL日志只持續化了一段，它的 WAL 日志段也沒有持久化成功。因此，根據一致性協議，當前 LogIndex 2 的日志在多數派節點上已經寫入成功，當前 Consensus Log的 CommitIndex 就是 2 ，對應的那 Commit LSN 就是300。

上圖為tpmC 測試過程中 RTO 的情況。tpmC 達到 30 萬左右的時候，進行kill 主庫的操作?？梢钥吹?#xff0c;不到 30 秒，新的主庫已經恢復了寫的能力，并且恢復到切換之前的水平。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的阿里云数据库开源发布：PolarDB三节点高可用的功能特性和关键技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。