關(guān)于 PolarDB PostgreSQL 版
PolarDB PostgreSQL 版是一款阿里云自主研發(fā)的云原生關(guān)系型數(shù)據(jù)庫(kù)產(chǎn)品，100% 兼容 PostgreSQL，高度兼容Oracle語(yǔ)法;采用基于 Shared-Storage 的存儲(chǔ)計(jì)算分離架構(gòu)，具有極致彈性、毫秒級(jí)延遲、HTAP 、Ganos全空間數(shù)據(jù)處理能力和高可靠、高可用、彈性擴(kuò)展等企業(yè)級(jí)數(shù)據(jù)庫(kù)特性。同時(shí)，PolarDB PostgreSQL 版具有大規(guī)模并行計(jì)算能力，可以應(yīng)對(duì) OLTP 與 OLAP 混合負(fù)載。
PolarDB PostgreSQL高可用架構(gòu)
傳統(tǒng)計(jì)算與存儲(chǔ)緊耦合的數(shù)據(jù)庫(kù)系統(tǒng)架構(gòu)面臨諸多挑戰(zhàn)，如：
1、存儲(chǔ)空間無(wú)法超過(guò)單機(jī)上限，不易實(shí)現(xiàn)資源的快速擴(kuò)容;
2、一臺(tái)物理機(jī)的不同資源難以同時(shí)具有較高的利用率，資源易碎片化;
3、單一資源故障會(huì)導(dǎo)致系統(tǒng)整體故障，系統(tǒng)恢復(fù)時(shí)間長(zhǎng)。
PolarDB PostgreSQL采用計(jì)算與存儲(chǔ)分離的架構(gòu)，相比于緊耦合架構(gòu)，存儲(chǔ)資源被單獨(dú)解耦組成一個(gè)獨(dú)立的存儲(chǔ)池，可獨(dú)立提高存儲(chǔ)池的資源利用率;同時(shí)主節(jié)點(diǎn)與多個(gè)只讀節(jié)點(diǎn)可共享同一份存儲(chǔ)，節(jié)約了只讀節(jié)點(diǎn)的存儲(chǔ)開(kāi)銷(xiāo)，進(jìn)一步降低了存儲(chǔ)成本;計(jì)算存儲(chǔ)分離的設(shè)計(jì)使得計(jì)算集群與存儲(chǔ)集群均可獨(dú)立擴(kuò)展，極大地提高了資源彈性;此外節(jié)點(diǎn)間通過(guò)日志信息來(lái)同步內(nèi)存狀態(tài)，不會(huì)產(chǎn)生IO，大大降低節(jié)點(diǎn)同步延遲，為極致高可用提供了基礎(chǔ)。
在計(jì)算存儲(chǔ)分離的架構(gòu)下，PolarDB PostgreSQL可同時(shí)提供AZ內(nèi)/跨AZ/跨域級(jí)別的高可用。這里把一個(gè)PolarDB數(shù)據(jù)庫(kù)計(jì)算與存儲(chǔ)節(jié)點(diǎn)，以及高可用控制模塊、運(yùn)維管理模塊，統(tǒng)稱(chēng)為一個(gè)PolarDB集群。從數(shù)據(jù)層面來(lái)看，PolarDB的高可用架構(gòu)如下：
單套PolarDB集群部署在一個(gè)可用區(qū)內(nèi)，不同的PolarDB集群之間互為災(zāi)備，主備模式保證跨AZ/跨域級(jí)別的高可用;
1、PolarDB集群為一寫(xiě)多讀架構(gòu)，讀寫(xiě)節(jié)點(diǎn)共享同一份存儲(chǔ)，有效降低存儲(chǔ)成本，同時(shí)只讀節(jié)點(diǎn)還可實(shí)現(xiàn)單個(gè)AZ內(nèi)計(jì)算節(jié)點(diǎn)的高可用;
2、DataMax節(jié)點(diǎn)只保存WAL日志文件，不與寫(xiě)節(jié)點(diǎn)共享數(shù)據(jù)，在提供遠(yuǎn)程同步功能的同時(shí)，可以更高效地實(shí)現(xiàn)跨域級(jí)別的高可用;
3、BackupAgent通過(guò)調(diào)用分布式文件系統(tǒng)的接口進(jìn)行快速數(shù)據(jù)備份，備份支持本地盤(pán)、OSS、DBS等，保證故障發(fā)生時(shí)可基于備份進(jìn)行數(shù)據(jù)的恢復(fù)，防止數(shù)據(jù)丟失/損壞;
4、MaxScale是代理層，可自動(dòng)識(shí)別讀寫(xiě)請(qǐng)求，根據(jù)只讀負(fù)載將讀請(qǐng)求發(fā)送給不同的只讀節(jié)點(diǎn)，通過(guò)讀寫(xiě)分離實(shí)現(xiàn)負(fù)載均衡。
在一個(gè)可用區(qū)內(nèi)，PolarDB的RW、RO節(jié)點(diǎn)間保持接近于實(shí)時(shí)的內(nèi)存同步，如果RW出現(xiàn)故障，可以隨時(shí)進(jìn)行RW/RO節(jié)點(diǎn)切換，實(shí)現(xiàn)單個(gè)AZ內(nèi)的高可用;在集群間，兩個(gè)集群通過(guò)日志進(jìn)行物理復(fù)制，中間有一個(gè)DataMax日志中繼節(jié)點(diǎn)，主集群與DataMax間配置為同步模式，遠(yuǎn)程集群配置為異步復(fù)制，從而在性能穩(wěn)定的情況下，保障跨AZ/跨域高可用的RPO=0。此外，如果用戶(hù)有3個(gè)可用區(qū)，還可以部署為Paxos三節(jié)點(diǎn)模式，其中一個(gè)節(jié)點(diǎn)只保存日志，從而實(shí)現(xiàn)低成本超高可用性能力。
從控制層面來(lái)看，PolarDB的高可用架構(gòu)如下：
其中：
1、Cluster Manager為集群管理中心，通過(guò)心跳數(shù)據(jù)監(jiān)控?cái)?shù)據(jù)庫(kù)實(shí)例、MaxScale及Agent的可用性，通過(guò)切換或重啟異常節(jié)點(diǎn)來(lái)維護(hù)集群的高可用，提供主動(dòng)監(jiān)控和快速檢測(cè)故障的能力;
2、運(yùn)行在主機(jī)上的不同Agent負(fù)責(zé)監(jiān)控、采集或配置數(shù)據(jù)庫(kù)實(shí)例和主機(jī)的信息，并生成對(duì)應(yīng)的監(jiān)控視圖，同時(shí)部分指標(biāo)也輸出至Cluster Manager中輔助決策;
3、管控負(fù)責(zé)資源管理及數(shù)據(jù)庫(kù)實(shí)例生命周期管理，其基于Agent采集的信息進(jìn)行監(jiān)控及告警，便于更快速及時(shí)地響應(yīng)并處理故障，同時(shí)提供web端供用戶(hù)查詢(xún)及修改，提供Open API接口給第三方平臺(tái)調(diào)用，使得數(shù)據(jù)庫(kù)的管理更加便捷。
PolarDB用戶(hù)可以根據(jù)自己的實(shí)際情況和SLA要求，在單可用區(qū)、雙可用區(qū)、三可用區(qū)、跨域等多種環(huán)境下，靈活的選擇可用性方案。下面分別對(duì)單可用區(qū)內(nèi)計(jì)算節(jié)點(diǎn)的高可用、雙可用區(qū)/跨域間計(jì)算集群的高可用、三可用區(qū)DMA高可用方案的核心技術(shù)及原理進(jìn)行詳細(xì)介紹。
計(jì)算節(jié)點(diǎn)高可用
PolarDB單個(gè)AZ內(nèi)計(jì)算節(jié)點(diǎn)的高可用通過(guò)只讀節(jié)點(diǎn)RO實(shí)現(xiàn)，讀寫(xiě)節(jié)點(diǎn)RW與只讀節(jié)點(diǎn)RO共享底層存儲(chǔ)數(shù)據(jù)，RW落盤(pán)的數(shù)據(jù)RO可直接讀取。因此當(dāng)讀寫(xiě)節(jié)點(diǎn)RW異常crash時(shí)，可通過(guò)將RO節(jié)點(diǎn)提升為RW節(jié)點(diǎn)來(lái)實(shí)現(xiàn)計(jì)算節(jié)點(diǎn)的高可用。由于RW節(jié)點(diǎn)與RO節(jié)點(diǎn)共享存儲(chǔ)，因此可保證RPO=0。為保證應(yīng)用層服務(wù)所見(jiàn)數(shù)據(jù)的一致性，RO節(jié)點(diǎn)提升為RW節(jié)點(diǎn)之后，需回放完存儲(chǔ)上的所有WAL日志數(shù)據(jù)才可對(duì)外提供服務(wù)，因此RO與RW之間的延遲對(duì)于RTO至關(guān)重要，而且越小越好。節(jié)點(diǎn)間是通過(guò)傳輸日志信息進(jìn)行同步的。注意這里只傳輸日志的Metadata信息，這些日志非常容易解析，這樣做可以讓RO以接近于實(shí)時(shí)的延遲接收、解析這些Metadata。接收這些信息后，RO查找自己的Bufferpool，如果Bufferpool有對(duì)應(yīng)的頁(yè)面，則對(duì)這些頁(yè)面進(jìn)行失效操作。當(dāng)RO上有查詢(xún)讀取到這些失效頁(yè)面，則對(duì)這些失效頁(yè)面單獨(dú)查找和應(yīng)用其對(duì)應(yīng)的日志，使其重新變?yōu)橛行У男掳姹卷?yè)面。這種技術(shù)有如下優(yōu)勢(shì)：
1、流復(fù)制只傳輸WAL Metadata數(shù)據(jù)，降低網(wǎng)絡(luò)傳輸量和解析時(shí)的CPU消耗;
2、日志同步時(shí)，只對(duì)內(nèi)存頁(yè)面做失效操作，無(wú)需讀取和應(yīng)用日志，不會(huì)有IO操作。
這樣，RO用最少的數(shù)據(jù)量和步驟完成了同步，實(shí)現(xiàn)了極致的(通常低于1ms)的RO與RW節(jié)點(diǎn)延遲，確保了RO一致性和可用性。下面詳細(xì)介紹這個(gè)同步過(guò)程。
節(jié)點(diǎn)間同步原理
先看下傳統(tǒng)主備模式下，流復(fù)制傳輸與備庫(kù)回放日志的過(guò)程：
1、當(dāng)RW節(jié)點(diǎn)中的事務(wù)對(duì)其數(shù)據(jù)進(jìn)行修改時(shí)，會(huì)生成對(duì)應(yīng)的WAL日志并將其寫(xiě)入walbuffer;
2、同步流復(fù)制模式下，事務(wù)提交時(shí)會(huì)先將walbuffer中對(duì)應(yīng)的WAL日志flush到磁盤(pán)，此后會(huì)喚醒WalSender進(jìn)程;
3、WalSender進(jìn)程發(fā)現(xiàn)有新的日志可以發(fā)送，則從磁盤(pán)中讀取對(duì)應(yīng)的日志數(shù)據(jù)，通過(guò)已建立的流復(fù)制連接發(fā)送到對(duì)端的Standby;
4、Standby的WalReceiver進(jìn)程接收到新的日志數(shù)據(jù)之后，同樣地將其flush到對(duì)應(yīng)的磁盤(pán)日志文件中，同時(shí)通知Startup進(jìn)程有新的日志到達(dá);
5、Startup從磁盤(pán)文件中讀取對(duì)應(yīng)的XLOG Record進(jìn)行回放。
在PolarDB這種共享存儲(chǔ)模式下，RW與RO共享底層存儲(chǔ)數(shù)據(jù)，因此RW無(wú)需傳輸WAL日志的全部?jī)?nèi)容至RO，只需傳輸WAL日志元信息META，RO可基于META直接從底層存儲(chǔ)上讀取所需要的WAL日志數(shù)據(jù)，如下所示：
1、當(dāng)RW節(jié)點(diǎn)中的事務(wù)對(duì)其數(shù)據(jù)進(jìn)行修改時(shí)，會(huì)生成對(duì)應(yīng)的WAL日志并將其寫(xiě)入walbuffer，同時(shí)拷貝對(duì)應(yīng)的WAL meta數(shù)據(jù)至內(nèi)存中的meta queue中;
2、同步流復(fù)制模式下，事務(wù)提交時(shí)會(huì)先將walbuffer中對(duì)應(yīng)的WAL日志flush到磁盤(pán)，此后會(huì)喚醒WalSender進(jìn)程;
3、WalSender進(jìn)程發(fā)現(xiàn)有新的日志可以發(fā)送，則從meta queue中讀取對(duì)應(yīng)的WAL meta，通過(guò)已建立的流復(fù)制連接發(fā)送到對(duì)端的RO;
4、RO的WalReceiver進(jìn)程接收到新的日志數(shù)據(jù)之后，將其push到內(nèi)存的meta queue中，同時(shí)通知Startup進(jìn)程有新的日志到達(dá);
5、Startup從meta queue中讀取對(duì)應(yīng)的meta數(shù)據(jù)，解析生成對(duì)應(yīng)的WAL Index memtable即可。
RO的Startup并不實(shí)質(zhì)讀取WAL日志并進(jìn)行數(shù)據(jù)回放操作，數(shù)據(jù)的回放被延后到真正有用戶(hù)進(jìn)程訪問(wèn)該page時(shí)進(jìn)行：
1、Startup回放進(jìn)程在接收到WAL meta數(shù)據(jù)后僅在內(nèi)存中生成對(duì)應(yīng)的WAL Index，同時(shí)若該WAL meta對(duì)應(yīng)的page存在于Buffer Pool中，則將其標(biāo)記為Outdate;
2、會(huì)話進(jìn)程進(jìn)行數(shù)據(jù)訪問(wèn)時(shí)，若該對(duì)應(yīng)的page不在Buffer Pool中，或在Buffer Pool中被標(biāo)記為Outdate，則基于WAL Index檢索屬于該頁(yè)面的需要回放的WAL日志，并從磁盤(pán)上讀取對(duì)應(yīng)的WAL日志數(shù)據(jù)進(jìn)行真正的回放操作，回放完成后向會(huì)話進(jìn)程返回對(duì)應(yīng)數(shù)據(jù)。
通過(guò)減少流復(fù)制過(guò)程中讀取/接收WAL引入的磁盤(pán)IO操作，同時(shí)減少網(wǎng)絡(luò)傳輸量，以及將真正的回放過(guò)程轉(zhuǎn)移到會(huì)話進(jìn)程中等優(yōu)化，加速了RO節(jié)點(diǎn)的內(nèi)存同步進(jìn)程，將RW與RO之間的延遲降至了最低(通常1ms以?xún)?nèi))，從而提升了RO的可用性。
Online Promote
在共享存儲(chǔ)架構(gòu)下，最簡(jiǎn)單的節(jié)點(diǎn)切換方式，是基于重啟的方式進(jìn)行HA切換。在這種方式中，RW異常crash之后，RO節(jié)點(diǎn)以RW身份重啟，此時(shí)新的RW需要從checkpoint點(diǎn)開(kāi)始回放完所有日志之后才可對(duì)外提供服務(wù)，當(dāng)checkpoint落后較多時(shí)，新的RW啟動(dòng)過(guò)程中需要回放較多的日志數(shù)據(jù)，導(dǎo)致異常crash后服務(wù)恢復(fù)時(shí)間長(zhǎng)。
為了避免重啟方式的問(wèn)題，PolarDB使用Online Promote的方式將RO提升為RW，該過(guò)程無(wú)需重啟RO節(jié)點(diǎn)：
在Online Promote過(guò)程中，Promote后RO從切換前的Replay回放位點(diǎn)繼續(xù)回放老的RW生成的日志。同樣的，RO節(jié)點(diǎn)的回放過(guò)程僅生成對(duì)應(yīng)的WAL Index數(shù)據(jù)，WAL Index生成完畢之后即可恢復(fù)服務(wù)，會(huì)話進(jìn)程訪問(wèn)Page時(shí)，基于WAL Index回放該P(yáng)age對(duì)應(yīng)的WAL日志，RO需要回放的日志數(shù)量并不受checkpoint影響，通過(guò)Online Promote減少RO需要回放的日志量，縮短回放時(shí)間，從而加快服務(wù)恢復(fù)的速度。
并行回放
除了上述兩點(diǎn)，PolarDB同時(shí)通過(guò)并行回放加速HA時(shí)RO的回放速度，原理如下所示。Dispatcher進(jìn)程將回放任務(wù)推送到各個(gè)進(jìn)程的任務(wù)隊(duì)列，進(jìn)程組中進(jìn)程讀取各自任務(wù)隊(duì)列中的任務(wù)進(jìn)行回放。
PolarDB通過(guò)優(yōu)化RO節(jié)點(diǎn)的內(nèi)存同步過(guò)程，極大地降低了RW與RO之間的延遲，同時(shí)通過(guò)Online Promote和并行回放加速了HA時(shí)服務(wù)的恢復(fù)速度，可在保障RPO為0的同時(shí)，以較低的RTO實(shí)現(xiàn)單個(gè)可用區(qū)內(nèi)的高可用。此外，PolarDB基于Cluster Manager，還可實(shí)現(xiàn)對(duì)集群狀態(tài)的主動(dòng)監(jiān)控及對(duì)故障的快速檢測(cè)，提供自動(dòng)化的故障處理恢復(fù)能力，保證服務(wù)的連續(xù)可用性，下面詳細(xì)介紹Cluster Manager的實(shí)現(xiàn)。
Cluster Manager
Cluster Manager負(fù)責(zé)集群及配置管理，自動(dòng)化的維護(hù)集群的高可用，其內(nèi)部模塊如下：
1、Detector探測(cè)模塊通過(guò)心跳請(qǐng)求探測(cè)數(shù)據(jù)庫(kù)的可用性，默認(rèn)為3s超時(shí)，當(dāng)發(fā)生超時(shí)時(shí)，同時(shí)會(huì)有一個(gè)backup心跳進(jìn)行輔助決策，避免特殊情況導(dǎo)致誤判，backup心跳默認(rèn)超時(shí)為60s;
3、Collector采集模塊獲取各個(gè)維度的實(shí)時(shí)監(jiān)控信息，包括操作系統(tǒng)、容器、存儲(chǔ)及數(shù)據(jù)庫(kù)內(nèi)核的多個(gè)指標(biāo)，結(jié)合所有指標(biāo)即可得到當(dāng)前數(shù)據(jù)庫(kù)實(shí)例的運(yùn)行狀態(tài)，用于分析及決策;
4、Decision決策模塊基于上述獲取的實(shí)例運(yùn)行狀態(tài)進(jìn)行決策，如對(duì)數(shù)據(jù)庫(kù)實(shí)例節(jié)點(diǎn)及MaxScale節(jié)點(diǎn)的可用性進(jìn)行決策，對(duì)實(shí)例及其狀態(tài)變更進(jìn)行決策;
5、Action執(zhí)行模塊實(shí)施Decision決策模塊下發(fā)的決策，如重啟數(shù)據(jù)庫(kù)節(jié)點(diǎn)，進(jìn)行HA切換，對(duì)實(shí)例進(jìn)行只讀鎖定等;
6、Plugin插件模塊獲取Manager提供的集群節(jié)點(diǎn)拓?fù)湫畔⒓柏?fù)載情況，便于其對(duì)自身的行為進(jìn)行調(diào)整。
部分典型的異常故障場(chǎng)景如下，Cluster Manager會(huì)依據(jù)多維度的信息進(jìn)行判斷與決策：
異常場(chǎng)景 決策數(shù)據(jù)
計(jì)算節(jié)點(diǎn)宕機(jī) 多維度超時(shí)、容器主機(jī)數(shù)據(jù)避免誤判
計(jì)算節(jié)點(diǎn)網(wǎng)絡(luò)中斷 多維度超時(shí)
計(jì)算節(jié)點(diǎn)網(wǎng)卡故障 多維度超時(shí)、網(wǎng)卡狀態(tài)監(jiān)控
計(jì)算節(jié)點(diǎn)存儲(chǔ)掛載丟失 心跳超時(shí)、存儲(chǔ)掛載狀態(tài)監(jiān)控
數(shù)據(jù)庫(kù)內(nèi)核Crash 心跳狀態(tài)
數(shù)據(jù)庫(kù)內(nèi)核OOM 心跳狀態(tài)、內(nèi)存狀態(tài)
數(shù)據(jù)庫(kù)IO hang 心跳超時(shí)、等待事件、IO指標(biāo)決策
計(jì)算節(jié)點(diǎn)丟包10% 心跳不持續(xù)性超時(shí)
計(jì)算節(jié)點(diǎn)網(wǎng)絡(luò)延遲100ms 心跳不持續(xù)性超時(shí)
RO回放延遲 復(fù)制狀態(tài)、buffer使用率
當(dāng)探測(cè)到節(jié)點(diǎn)不可用時(shí)，Cluster Manager會(huì)進(jìn)一步下發(fā)恢復(fù)策略：
1、若RO節(jié)點(diǎn)不可用，則對(duì)RO節(jié)點(diǎn)進(jìn)行重建;
2、若RW節(jié)點(diǎn)不可用，則進(jìn)一步判斷RO節(jié)點(diǎn)狀態(tài)，若RO節(jié)點(diǎn)可用，則觸發(fā)HA切換，篩選符合要求的RO，將其提升為RW，并重建RO;
3、若RW與RO節(jié)點(diǎn)同時(shí)不可用，則先進(jìn)行重啟，若RW與RO節(jié)點(diǎn)持續(xù)不可用，則進(jìn)一步判斷Standby節(jié)點(diǎn)是否可用，若可用則觸發(fā)切換，篩選符合要求的Standby，將其提升為RW，并重建Standby。
Cluster Manager實(shí)現(xiàn)了自動(dòng)化的監(jiān)控、切換決策、切換流程，在不需要用戶(hù)干預(yù)的情況下，確保了RTO。Cluster Manager可對(duì)多個(gè)可用區(qū)的實(shí)例狀態(tài)進(jìn)行監(jiān)控，實(shí)現(xiàn)AZ內(nèi)/跨AZ/跨域級(jí)別的自動(dòng)化故障檢測(cè)及恢復(fù)，下面對(duì)跨可用區(qū)的計(jì)算集群間的高可用實(shí)現(xiàn)進(jìn)行介紹。
計(jì)算集群高可用
DataMax節(jié)點(diǎn)
PolarDB通過(guò)增加RO只讀節(jié)點(diǎn)實(shí)現(xiàn)單個(gè)AZ內(nèi)計(jì)算節(jié)點(diǎn)的高可用，同時(shí)增加DataMax節(jié)點(diǎn)來(lái)更高效地實(shí)現(xiàn)計(jì)算集群的高可用。PolarDB基于物理流復(fù)制實(shí)現(xiàn)主庫(kù)與備庫(kù)之間的數(shù)據(jù)同步，主庫(kù)與備庫(kù)的流復(fù)制模式包含同步及異步兩種：
1、異步模式下，主庫(kù)的事務(wù)提交僅需等待對(duì)應(yīng)日志寫(xiě)入本地磁盤(pán)文件中后，即可進(jìn)行之后的提交操作，備庫(kù)的狀態(tài)對(duì)主庫(kù)的性能無(wú)影響。但異步模式下無(wú)法保證RPO=0，備庫(kù)相較主庫(kù)存在一定的延遲，若主庫(kù)所在的集群出現(xiàn)故障，此時(shí)切換至備庫(kù)可能存在數(shù)據(jù)丟失;
2、同步模式包含不同的級(jí)別，可通過(guò)synchronous_commit參數(shù)進(jìn)行設(shè)置，包括：
1)remote_write：該模式下，主庫(kù)的事務(wù)提交需等待對(duì)應(yīng)日志寫(xiě)入主庫(kù)磁盤(pán)文件及備庫(kù)的系統(tǒng)緩存中后，才能進(jìn)行之后的事務(wù)提交操作;
2)on：該模式下，主庫(kù)的事務(wù)提交需等待對(duì)應(yīng)日志都已寫(xiě)入主庫(kù)及備庫(kù)的磁盤(pán)文件中后，才能進(jìn)行之后的事務(wù)提交操作;
3)remote_apply：該模式下，主庫(kù)的事務(wù)提交需等待對(duì)應(yīng)日志寫(xiě)入主庫(kù)及備庫(kù)的磁盤(pán)文件中，同時(shí)備庫(kù)已經(jīng)回放完對(duì)應(yīng)日志使其對(duì)備庫(kù)上的查詢(xún)可見(jiàn)后，才能進(jìn)行之后的事務(wù)提交操作。
同步模式保證了主庫(kù)的事務(wù)提交操作需等待備庫(kù)接收到對(duì)應(yīng)的日志數(shù)據(jù)之后才可執(zhí)行，從而實(shí)現(xiàn)了主庫(kù)與備庫(kù)之間的零數(shù)據(jù)丟失，可保證RPO=0。但同時(shí)，該模式下主庫(kù)的事務(wù)提交操作依賴(lài)備庫(kù)的日志接收結(jié)果，因此若主備之間距離較遠(yuǎn)導(dǎo)致傳輸延遲較大時(shí)，同步模式會(huì)對(duì)主庫(kù)的性能帶來(lái)影響;極端情況下，若備庫(kù)異常crash，則此時(shí)主庫(kù)則會(huì)一直阻塞在等待備庫(kù)的過(guò)程中，導(dǎo)致無(wú)法正常提供服務(wù)。
針對(duì)傳統(tǒng)主備模式下同步復(fù)制對(duì)主庫(kù)性能影響較大的問(wèn)題，PolarDB新增DataMax節(jié)點(diǎn)用于實(shí)現(xiàn)遠(yuǎn)程同步，如下：
1、DataMax節(jié)點(diǎn)僅保存WAL日志文件，并不對(duì)日志進(jìn)行回放操作，不保存RW節(jié)點(diǎn)的數(shù)據(jù)文件，降低存儲(chǔ)成本;
2、DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)數(shù)據(jù)不共享，兩者的存儲(chǔ)設(shè)備彼此隔離，以防止計(jì)算集群存儲(chǔ)異常導(dǎo)致的RW節(jié)點(diǎn)與DataMax節(jié)點(diǎn)保存的日志都丟失;
3、DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)之間為同步復(fù)制模式，確保RPO=0，DataMax部署在距離RW節(jié)點(diǎn)較近的區(qū)域，通常與RW節(jié)點(diǎn)位于同一可用區(qū)，以減小日志同步對(duì)主庫(kù)帶來(lái)的性能影響;
4、DataMax節(jié)點(diǎn)將其自身接收日志發(fā)送至其他可用區(qū)的Standby節(jié)點(diǎn)，Standby節(jié)點(diǎn)接收并回放DataMax節(jié)點(diǎn)的日志實(shí)現(xiàn)與RW節(jié)點(diǎn)的遠(yuǎn)程同步，Standby節(jié)點(diǎn)與DataMax節(jié)點(diǎn)之間可設(shè)置為異步流復(fù)制模式，通過(guò)DataMax節(jié)點(diǎn)可分流RW節(jié)點(diǎn)向多個(gè)備份數(shù)據(jù)庫(kù)傳輸日志的開(kāi)銷(xiāo)。
集群高可用
如下，若RW節(jié)點(diǎn)與RO節(jié)點(diǎn)同時(shí)異常，或存儲(chǔ)無(wú)法提供服務(wù)時(shí)，則可將位于不同可用區(qū)的Standby節(jié)點(diǎn)提升為RW節(jié)點(diǎn)，保證服務(wù)的可用性。在將Standby節(jié)點(diǎn)提升為RW節(jié)點(diǎn)并向外提供服務(wù)之前，會(huì)確認(rèn)Standby節(jié)點(diǎn)是否已從DataMax節(jié)點(diǎn)拉取完畢所有日志，由于DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)為同步復(fù)制，因此可保證該場(chǎng)景下RPO=0。
若DataMax節(jié)點(diǎn)異常，則優(yōu)先嘗試重啟進(jìn)行恢復(fù)，若重啟失敗則對(duì)其進(jìn)行重建，因DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)存儲(chǔ)彼此隔離，因此兩者數(shù)據(jù)并不互相影響，此外DataMax節(jié)點(diǎn)可同樣采取計(jì)算存儲(chǔ)分離架構(gòu)，確保DataMax節(jié)點(diǎn)的異常不會(huì)導(dǎo)致其存儲(chǔ)的WAL日志數(shù)據(jù)丟失。
類(lèi)似地，DataMax節(jié)點(diǎn)實(shí)現(xiàn)了如下幾種日志同步模式，用戶(hù)可以根據(jù)具體業(yè)務(wù)需求進(jìn)行相應(yīng)配置：
1、最大保護(hù)模式
1)該模式下，DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)進(jìn)行日志強(qiáng)同步，確保RPO=0;
2)若DataMax節(jié)點(diǎn)因網(wǎng)絡(luò)或硬件故障無(wú)法提供服務(wù)，RW節(jié)點(diǎn)也會(huì)因此阻塞而無(wú)法對(duì)外提供服務(wù);
2、最大性能模式
1)該模式下，DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)進(jìn)行日志異步流復(fù)制，DataMax節(jié)點(diǎn)不對(duì)RW節(jié)點(diǎn)性能帶來(lái)影響，DataMax節(jié)點(diǎn)異常也不會(huì)影響RW節(jié)點(diǎn)的服務(wù);
2)若RW節(jié)點(diǎn)下的存儲(chǔ)或?qū)?yīng)的集群發(fā)生故障，則可能導(dǎo)致丟失較多數(shù)據(jù)，無(wú)法確保RPO=0;
3、最大高可用模式
1)該模式下，當(dāng)DataMax節(jié)點(diǎn)正常工作時(shí)，DataMax節(jié)點(diǎn)與RW節(jié)點(diǎn)進(jìn)行日志強(qiáng)同步，即為最大保護(hù)模式;
2)若DataMax節(jié)點(diǎn)異常，則RW節(jié)點(diǎn)將同步模式降級(jí)為最大性能模式，保證RW節(jié)點(diǎn)服務(wù)的持續(xù)可用;
3)當(dāng)DataMax節(jié)點(diǎn)恢復(fù)正常后，則RW節(jié)點(diǎn)再次將異步模式提升為最大保護(hù)模式，避免日志數(shù)據(jù)出現(xiàn)較多丟失。
通過(guò)DataMax日志中繼節(jié)點(diǎn)降低日志同步延遲、分流RW節(jié)點(diǎn)的日志傳輸壓力，可在性能穩(wěn)定的情況下，保障跨AZ/跨域高可用的RPO=0。
DMA高可用
上述方式實(shí)現(xiàn)的集群高可用需通過(guò)日志強(qiáng)同步保證RPO=0，當(dāng)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)或備份節(jié)點(diǎn)故障時(shí)，都會(huì)對(duì)集群的可用性帶來(lái)影響。此外，集群節(jié)點(diǎn)可用性的判斷與高可用決策依賴(lài)Cluster Manager，數(shù)據(jù)庫(kù)集群本身不具備自主高可用或自運(yùn)維能力，針對(duì)此，PolarDB同時(shí)提供了基于DMA的高可用形態(tài)(即三節(jié)點(diǎn)形態(tài))，具體如下：
1、DMA在數(shù)據(jù)庫(kù)內(nèi)核中引入Raft分布式協(xié)議，基于X-Paxos進(jìn)行日志同步，同時(shí)可對(duì)主備節(jié)點(diǎn)狀態(tài)進(jìn)行管理及協(xié)調(diào)，在發(fā)生故障時(shí)進(jìn)行自主failover，具備自主運(yùn)維及自主高可用能力;
2、DMA具備跨域高可用能力，可容忍N(yùn)/2 - 1個(gè)節(jié)點(diǎn)故障，在少數(shù)節(jié)點(diǎn)故障時(shí)仍能保證RPO=0;
3、DMA可將X-Paxos與Cluster Manager相結(jié)合，保證故障發(fā)生后的RTO < 30s;
4、DMA對(duì)WAL日志流和Consensus日志流的傳輸鏈路進(jìn)行了優(yōu)化，可實(shí)現(xiàn)性能損耗相較于單機(jī)下降在10%以?xún)?nèi);
5、DMA可同時(shí)接入DataMax作為其Logger節(jié)點(diǎn)，從而降低部署成本;此外該高可用架構(gòu)還可保持與傳統(tǒng)主備復(fù)制及原有工具如DTS的兼容。
Consensus與WAL雙日志流
引入X-Paxos之后，DMA需通過(guò)Consensus日志復(fù)制來(lái)維護(hù)集群數(shù)據(jù)的一致性，同時(shí)主節(jié)點(diǎn)與備節(jié)點(diǎn)之間還需要WAL日志復(fù)制來(lái)實(shí)現(xiàn)數(shù)據(jù)同步，針對(duì)該問(wèn)題，DMA采用了Consensus log與WAL log雙日志流的方式：
其中WAL日志復(fù)制采用原生方式，保持與社區(qū)的兼容性。Consensus日志與WAL日志獨(dú)立，僅在Consensus日志中記錄WAL日志位點(diǎn)，Consensus日志提交成功即代表相應(yīng)位點(diǎn)之前的WAL日志也在多數(shù)派上提交成功。此外，DMA還對(duì)雙日志流的傳輸進(jìn)行了優(yōu)化，加快了雙日志流的傳輸速度，從而提升了整個(gè)集群的可用性，下面詳細(xì)對(duì)此進(jìn)行介紹。
日志傳輸鏈路優(yōu)化
1、DMA中的日志傳輸流程如下：
2、Leader進(jìn)行事務(wù)提交時(shí)，會(huì)生成對(duì)應(yīng)的WAL日志并寫(xiě)入WAL buffer中;
3、Leader將Commit Record LSN之前的WAL日志刷盤(pán)，并喚醒WalSender進(jìn)程將WAL日志傳輸至各個(gè)Follower節(jié)點(diǎn)
4、Leader的WalSender進(jìn)程將WAL日志發(fā)送至Follower節(jié)點(diǎn);
5、Follower節(jié)點(diǎn)的WalReceiver進(jìn)程接收到WAL日志后寫(xiě)入本地WAL日志文件;
6、Leader通知Consensus服務(wù)進(jìn)程WAL日志已落盤(pán)，并等待該LSN位點(diǎn)多數(shù)派持久化成功;
7、Leader傳輸WAL日志的同時(shí)，Consensus服務(wù)進(jìn)程使用當(dāng)前Flush LSN生成Consensus Entry，并通知X-Paxos多數(shù)派復(fù)制Entry;
8、Leader的X-Paxos調(diào)用Consensus Log/Consensus service接口本地持久化Entry內(nèi)容;
9、Leader的X-Paxos向各個(gè)Follower發(fā)送Consensus Entry;
10、Follower的X-Paxos調(diào)用Consensus Log/Consensus service接口持久化Entry內(nèi)容;
11、Follower的X-Paxos向Leader response本地持久化等信息;
Leader的X-Paxos嘗試更新commitIndex信息，推進(jìn)后喚醒等待中的進(jìn)程，完成事務(wù)提交操作。
從上述流程可知，整個(gè)提交流程至少包含三次IO操作及兩次網(wǎng)絡(luò)交互，即上圖中1～5的步驟，其中WAL日志傳輸與接收，同Consensus日志的生成與傳輸可同步進(jìn)行，該提交流程對(duì)提交時(shí)延及IOPS均會(huì)帶來(lái)一定的影響。針對(duì)此，DMA首先將持久化Consensus Entry的IO操作與WAL Flush操作進(jìn)行了合并。如下，Leader節(jié)點(diǎn)在生成對(duì)應(yīng)WAL日志時(shí)，同時(shí)依據(jù)當(dāng)前Commit Record LSN生成對(duì)應(yīng)Consensus Entry，放入Consensus Entry SLRU中，類(lèi)似地，F(xiàn)ollower節(jié)點(diǎn)確保相應(yīng)的WAL日志已接收完成后，將Consensus Entry寫(xiě)入SLRU中。Leader節(jié)點(diǎn)及Follower節(jié)點(diǎn)持久化Entry的操作均可異步進(jìn)行。
同時(shí)將Leader FLush WAL的操作與發(fā)送雙日志流的操作并行化，兩者結(jié)合之后，整個(gè)提交流程路徑為：
Max(1 I/O, (Max(1 RTT, 1 RTT +1 I/O) + 1 RTT)) = 1 I/O + 2 RTT，即僅包含一次IO操作和兩次網(wǎng)絡(luò)交互。在此基礎(chǔ)上，還可將Follower節(jié)點(diǎn)的網(wǎng)絡(luò)接收與WAL日志落盤(pán)并行化，從而進(jìn)一步提升日志傳輸?shù)男阅堋?/p>
DMA三節(jié)點(diǎn)形態(tài)在保障RPO為0的同時(shí)，提升了對(duì)集群節(jié)點(diǎn)故障的容忍程度，使得集群自身具備了自主運(yùn)維及自主高可用的能力，同時(shí)結(jié)合日志節(jié)點(diǎn)與日志傳輸優(yōu)化，降低了高可用的實(shí)現(xiàn)成本與性能損耗。
總結(jié)
高可用是云原生數(shù)據(jù)庫(kù)中不可或缺的一環(huán)，本文對(duì)PolarDB PostgreSQL版的高可用架構(gòu)及幾種典型的高可用實(shí)現(xiàn)方案進(jìn)行了分析及介紹。PolarDB PostgreSQL通過(guò)RO/DataMax/DMA，可實(shí)現(xiàn)AZ內(nèi)/跨AZ/跨域的高可用，并引入X-Paxos使內(nèi)核具有故障感知及自主運(yùn)維的能力，同時(shí)結(jié)合Cluster Manager根據(jù)多維狀態(tài)配置策略進(jìn)行故障探測(cè)和下發(fā)恢復(fù)決策，降低誤判提升集群穩(wěn)定性。此外，在保證RPO=0的同時(shí)，PolarDB PostgreSQL通過(guò)WAL Index、Online Promote、DMA日志傳輸鏈路優(yōu)化等方式進(jìn)一步提升從故障中恢復(fù)的速度，盡可能地保證服務(wù)最少中斷或不中斷。目前PolarDB PostgreSQL仍在持續(xù)探索及優(yōu)化，以在保障RPO=0的基礎(chǔ)上，以更低的成本、更快的速度、更全面的形態(tài)實(shí)現(xiàn)一體化、系統(tǒng)化的高可用解決方案。
來(lái)源：阿里云PolarDB