阿里雲資料庫開源重磅釋出：PolarDB三節點高可用的功能特性和關鍵技術
簡介：在3月2日的阿里雲開源 PolarDB 企業級架構釋出會上，阿里雲資料庫技術專家孟勃榮 帶來了主題為《PolarDB 三節點高可用》的精彩演講。三節點高可用功能主要為 PolarDB 提供金融級強一致性、高可靠性的跨機房複製能力，基於分散式共識演算法同步資料庫物理日誌，自動failover，任意節點故障後資料零丟失。本議題主要介紹PolarDB三節點高可用的功能特性和關鍵技術。
在3月2日的阿里雲開源 PolarDB 企業級架構釋出會上，阿里雲資料庫技術專家孟勃榮
帶來了主題為《PolarDB 三節點高可用》的精彩演講。三節點高可用功能主要為 PolarDB 提供金融級強一致性、高可靠性的跨機房複製能力，基於分散式共識演算法同步資料庫物理日誌，自動failover，任意節點故障後資料零丟失。本議題主要介紹PolarDB三節點高可用的功能特性和關鍵技術。
直播回顧視訊：
以下根據釋出會演講視訊內容整理：
PolarDB for PostgreSQL三節點高可用功能主要是將物理複製與一致性協議相結合，為PolarDB 提供金融級強一致性以及高可靠的跨機房複製能力。
同步複製的主要目標是保證資料不丟失，但它同時也會帶來三個問題：
① 無法滿足可用性的要求，備庫出現故障或網路鏈路抖動的時候，會影響主庫的可用性，這對生產環境是不可接受的。其次它不能完全保證資料不丟失，同步複製保證資料不丟失的方案是當備機沒有完全持久化RW日誌前，主庫的事務不能提交。在某種極端情況下，比如主庫已經寫入了WAL日誌，等待備庫同步WAL日誌的過程中主庫發生了重啟，那麼在重啟的過程中，日誌回放的過程是不等待備庫持久化的。所以回放完成後，有可能備庫沒有持久化，而日誌在主庫上回放完之後已經對外可見了。
② 不具備故障自動切換的能力。自動切換、可用性探測等能力都依賴於外部的元件。
③ 舊的主庫在故障恢復之後，可能無法直接加入到叢集。比如當事務在主庫上的WAL日誌已經持久化，而備庫還未收到日誌或者還未持久化。此時如果主庫出現了故障，備庫切換成主庫後，舊的主庫重新執行後，因為在重啟之前有多餘的 WAL 日誌，所以無法直接從主庫上拉取日誌，必須依賴於其他工具對其一致性進行處理後才能加入到叢集裡。
非同步複製相比於同步複製，效能比較好，可用性也更高，因為備機的故障或網路鏈路的抖動不會影響主庫，但它最大的問題是丟資料。比如原來在主庫上能看到的資料，發生切換之後在備庫上不存在。其次，它也不具備自動故障切換和自動探測的能力，切換後的主庫無法自動加入到叢集裡。
Quorum複製使用了多數派的方案之後，可能也能保證不丟資料，但它並沒有涉及到當主機發生故障時如何選取新的主機；其次，每個節點的日誌不一致時，如何確保日誌的一致性；第三，叢集發生變更的時候，如何保證叢集狀態最終的一致性。針對以上問題，Quorum複製沒有提供完整的解決方案。所以本質上來說， PG 的 Quorum 複製並不是一個完整的、不丟資料的高可用方案。
整個高可用方案是一個單點寫入、多點可讀的集群系統。 Leader 節點作為單點寫入節點對外提供讀寫服務，產生了WAL日誌後向其他節點同步。Follower 主要是接受來自於 Leader 節點的 WAL 日誌，並進行回放，對外提供只讀服務。
那麼它的主要能力是包括以下三個方面：
保證叢集內資料的強一致性，即 RPO=0。當多數派節點的WAL日誌寫入成功後，才認為此日誌在叢集層面已經提交成功。發生故障時，其他Follower 節點會自動與 Leader 節點對齊日誌。
自動 failover 。在高可用叢集中，只要半數以上的節點存活，就能保證叢集正常對外提供服務。因此當少數 failover 故障或少數節點網路不通的時候，並不會影響叢集的服務能力。
當 Leader 節點故障或與多數派節點網路不通的時候，會自動觸發叢集重新選主流程，由新主對外提供讀寫服務。另外 Follower 節點也會自動從新的 Leader 節點上同步WAL日誌，並且自動與新的 Leader 日誌對齊。此時如果Follower 上的日誌比新 Leader 上多，則會自動從新 Leader 上對齊WAL日誌。
線上叢集變更可以支援線上增刪節點、手動切換、角色變換，比如從 Leader 切到 follower角色。此外還能支援所有節點設定選舉權重，選舉權重高的節點會優先被選為主。同時，叢集變更操作不影響業務的正常執行，此能力的實現由一致性協議來保證。最終叢集內配置達成一致，不會因為叢集配置過程中的異常情況導致狀態不一致的問題。
Learner 節點的日誌同步狀態與 Leader 無關，也不會影響 Leader ，它的主要作用有兩點：
① 作為加節點的中間狀態。比如新加的 Leader 節點延遲比較大，如果直接將其加入到多數派裡，會影響多數派的提交。因此，先以 learner 的角色加入到叢集來同步資料，當它的資料基本追上 Leader 之後，再升為 follower節點。
② 作為異地災備節點。它不會影響主庫的可用性，發生 Leader 切換之後，它能自動從新的賬號同步日誌，不需要外部的介入。
在叢集部署方面，能夠支援跨機房和跨域的部署，包括同機房三副本、同城三機房三副本，以及兩地三機房五副本、三地三機房五副本等。另外跨域也可以利用 Learner 節點進行災備，不會影響 Leader 節點的可用性。
此外，它相容了 PG 原生的流複製和邏輯複製，能夠保證下游的消費不受影響，保證下游不會出現未提交的資料。
從前文的介紹中可以看到，在 PolarDB 的高可用方案中，至少要儲存三份資料，儲存成本會有所增加。針對這個問題，我們提供了兩個方面的解決方案：
① 通過原生的非同步流複製來傳輸或同步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。
本文為阿里雲原創內容，未經允許不得轉載。