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

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

直播回顧視頻：開源PolarDB企業(yè)級架構(gòu)重磅發(fā)布-阿里云
PDF下載：?文件下載-阿里云開發(fā)者社區(qū)

以下根據(jù)發(fā)布會演講視頻內(nèi)容整理：

PolarDB for PostgreSQL三節(jié)點(diǎn)高可用功能主要是將物理復(fù)制與一致性協(xié)議相結(jié)合，為PolarDB 提供金融級強(qiáng)一致性以及高可靠的跨機(jī)房復(fù)制能力。

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

同步復(fù)制的主要目標(biāo)是保證數(shù)據(jù)不丟失，但它同時(shí)也會帶來三個(gè)問題：

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

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

③ 舊的主庫在故障恢復(fù)之后，可能無法直接加入到集群。比如當(dāng)事務(wù)在主庫上的WAL日志已經(jīng)持久化，而備庫還未收到日志或者還未持久化。此時(shí)如果主庫出現(xiàn)了故障，備庫切換成主庫后，舊的主庫重新運(yùn)行后，因?yàn)樵谥貑⒅坝卸嘤嗟?WAL 日志，所以無法直接從主庫上拉取日志，必須依賴于其他工具對其一致性進(jìn)行處理后才能加入到集群里。

異步復(fù)制相比于同步復(fù)制，性能比較好，可用性也更高，因?yàn)閭錂C(jī)的故障或網(wǎng)絡(luò)鏈路的抖動不會影響主庫，但它最大的問題是丟數(shù)據(jù)。比如原來在主庫上能看到的數(shù)據(jù)，發(fā)生切換之后在備庫上不存在。其次，它也不具備自動故障切換和自動探測的能力，切換后的主庫無法自動加入到集群里。

Quorum復(fù)制使用了多數(shù)派的方案之后，可能也能保證不丟數(shù)據(jù)，但它并沒有涉及到當(dāng)主機(jī)發(fā)生故障時(shí)如何選取新的主機(jī)；其次，每個(gè)節(jié)點(diǎn)的日志不一致時(shí)，如何確保日志的一致性；第三，集群發(fā)生變更的時(shí)候，如何保證集群狀態(tài)最終的一致性。針對以上問題，Quorum復(fù)制沒有提供完整的解決方案。所以本質(zhì)上來說， PG 的 Quorum 復(fù)制并不是一個(gè)完整的、不丟數(shù)據(jù)的高可用方案。

我們的方案是將阿里內(nèi)部的一致性協(xié)議 X-Paxos 引入進(jìn)來協(xié)調(diào)物理復(fù)制。X-Paxos 在阿里內(nèi)部和阿里云的多個(gè)產(chǎn)品上已經(jīng)穩(wěn)定運(yùn)行了很長時(shí)間，因此它的穩(wěn)定性得以保障。它的的一致性協(xié)議的算法和其他的協(xié)議是類似的。

整個(gè)高可用方案是一個(gè)單點(diǎn)寫入、多點(diǎn)可讀的集群系統(tǒng)。 Leader 節(jié)點(diǎn)作為單點(diǎn)寫入節(jié)點(diǎn)對外提供讀寫服務(wù)，產(chǎn)生了WAL日志后向其他節(jié)點(diǎn)同步。Follower 主要是接受來自于 Leader 節(jié)點(diǎn)的 WAL 日志，并進(jìn)行回放，對外提供只讀服務(wù)。

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

保證集群內(nèi)數(shù)據(jù)的強(qiáng)一致性，即 RPO=0。當(dāng)多數(shù)派節(jié)點(diǎn)的WAL日志寫入成功后，才認(rèn)為此日志在集群層面已經(jīng)提交成功。發(fā)生故障時(shí)，其他Follower 節(jié)點(diǎn)會自動與 Leader 節(jié)點(diǎn)對齊日志。

自動 failover 。在高可用集群中，只要半數(shù)以上的節(jié)點(diǎn)存活，就能保證集群正常對外提供服務(wù)。因此當(dāng)少數(shù) failover 故障或少數(shù)節(jié)點(diǎn)網(wǎng)絡(luò)不通的時(shí)候，并不會影響集群的服務(wù)能力。

當(dāng) Leader 節(jié)點(diǎn)故障或與多數(shù)派節(jié)點(diǎn)網(wǎng)絡(luò)不通的時(shí)候，會自動觸發(fā)集群重新選主流程，由新主對外提供讀寫服務(wù)。另外 Follower 節(jié)點(diǎn)也會自動從新的 Leader 節(jié)點(diǎn)上同步WAL日志，并且自動與新的 Leader 日志對齊。此時(shí)如果Follower 上的日志比新 Leader 上多，則會自動從新 Leader 上對齊WAL日志。

在線集群變更可以支持在線增刪節(jié)點(diǎn)、手動切換、角色變換，比如從 Leader 切到 follower角色。此外還能支持所有節(jié)點(diǎn)設(shè)置選舉權(quán)重，選舉權(quán)重高的節(jié)點(diǎn)會優(yōu)先被選為主。同時(shí)，集群變更操作不影響業(yè)務(wù)的正常運(yùn)行，此能力的實(shí)現(xiàn)由一致性協(xié)議來保證。最終集群內(nèi)配置達(dá)成一致，不會因?yàn)榧号渲眠^程中的異常情況導(dǎo)致狀態(tài)不一致的問題。

三節(jié)點(diǎn)高可用功能中增加了一個(gè)新的角色： Learner 節(jié)點(diǎn)。它沒有多數(shù)派的決策權(quán)，但能夠提供只讀服務(wù)。

Learner 節(jié)點(diǎn)的日志同步狀態(tài)與 Leader 無關(guān)，也不會影響 Leader ，它的主要作用有兩點(diǎn)：

① 作為加節(jié)點(diǎn)的中間狀態(tài)。比如新加的 Leader 節(jié)點(diǎn)延遲比較大，如果直接將其加入到多數(shù)派里，會影響多數(shù)派的提交。因此，先以 learner 的角色加入到集群來同步數(shù)據(jù)，當(dāng)它的數(shù)據(jù)基本追上 Leader 之后，再升為 follower節(jié)點(diǎn)。

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

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

此外，它兼容了 PG 原生的流復(fù)制和邏輯復(fù)制，能夠保證下游的消費(fèi)不受影響，保證下游不會出現(xiàn)未提交的數(shù)據(jù)。

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

首先，提高資源的利用率。 Follower 節(jié)點(diǎn)可以作為只讀節(jié)點(diǎn)來提供讀服務(wù)，從而增加整個(gè)集群的讀擴(kuò)展能力；此外，支持跨節(jié)點(diǎn)的并行查詢能力，可以充分利用各個(gè)基節(jié)點(diǎn)的資源。

其次，引入了日志節(jié)點(diǎn)，減少資源的占用。日志節(jié)點(diǎn)本身不存儲數(shù)據(jù)，它只存儲實(shí)時(shí)的WAL 日志，僅作為日志持久化的多數(shù)派節(jié)點(diǎn)之一。此日志節(jié)點(diǎn)本身也具備完整的日志復(fù)制能力，可以兼容原生的流復(fù)制和邏輯復(fù)制，可以將其作為下游日志消費(fèi)的源，從而減少 Leader 節(jié)點(diǎn)的日志傳輸壓力。可以根據(jù)下游日志消費(fèi)的需求，來定制日志節(jié)點(diǎn)的網(wǎng)絡(luò)規(guī)格或者其他資源。

一致性協(xié)議復(fù)制的基本原理主要包含三個(gè)方面：

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

② 由一致性協(xié)議來推動集群的提交位點(diǎn)。

③ 針對自動 failover 的問題，根據(jù)一致性協(xié)議層面自身狀態(tài)的變化，來驅(qū)動數(shù)據(jù)庫層面的狀態(tài)變化。比如心跳超時(shí)之后，可能會自動降級。

具體實(shí)現(xiàn)上，以 Consensus Log 為載體來推進(jìn)提交位點(diǎn)。針對每一段WAL日志生成相應(yīng)的 Consensus Log Entry ，里面記錄了WAL日志的結(jié)束 LSN。 而后引入一個(gè)持久化依賴，保證每個(gè) Log Entry持久化的時(shí)候，本節(jié)點(diǎn)上相應(yīng)位點(diǎn)的WAL日志已經(jīng)持久化成功。

引入上述兩個(gè)機(jī)制后，如果一致性協(xié)議層面認(rèn)為 Consensus Log 已經(jīng)提交成功，則意味著 Consensus Log 已經(jīng)在多數(shù)派上持久化成功，相應(yīng)位點(diǎn)的WAL日志肯定也已經(jīng)持久化成功。

以上圖為例， Leader 上已經(jīng)持久化了三段 WAL 日志，在 Follower 1 節(jié)點(diǎn)上，雖然 log entry 的 WAL 日志已經(jīng)持久化成功，但它對應(yīng)的 Consensus Log還未持久化成功，所以一致性協(xié)議就認(rèn)為此 Consensus Log也沒有持久化成功。Follower 2 上 Log Entry和Consensus Log 沒有持久化，它的WAL日志只持續(xù)化了一段，它的 WAL 日志段也沒有持久化成功。因此，根據(jù)一致性協(xié)議，當(dāng)前 LogIndex 2 的日志在多數(shù)派節(jié)點(diǎn)上已經(jīng)寫入成功，當(dāng)前 Consensus Log的 CommitIndex 就是 2 ，對應(yīng)的那 Commit LSN 就是300。

上圖為tpmC 測試過程中 RTO 的情況。tpmC 達(dá)到 30 萬左右的時(shí)候，進(jìn)行kill 主庫的操作。可以看到，不到 30 秒，新的主庫已經(jīng)恢復(fù)了寫的能力，并且恢復(fù)到切換之前的水平。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。