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