一、背景
AnalyticDB PostgreSQL版（簡稱ADB PG）是阿裡雲資料庫團隊基于PostgreSQL核心（簡稱PG）打造的一款雲原生資料倉庫産品。在資料實時互動式分析、HTAP、ETL、BI報表生成等業務場景，ADB PG都有着獨特的技術優勢。
作為一款企業級資料倉庫産品，資料安全的重要性不言而喻。備份恢複功能是保障資料安全的基本手段，也是ADB PG應對突發狀況進行資料庫恢複的重要保障。備份恢複，顧名思義，是對資料庫進行資料備份，以便在必要時進行資料的恢複，防範于未然。目前，ADB PG的備份恢複功能已經應用在以下各個使用者場景中：
- 由于系統故障、人為誤操作造成資料被破壞或執行個體不可用時，基于備份資料對執行個體進行恢複。
- 使用者需要基于已有執行個體，快速克隆出一個完全相同的執行個體。
- 在節點數不變的前提下，使用者需要更改源執行個體的規格。
本文将介紹ADB PG備份恢複的原理與使用方法。
二、簡介
ADB PG 是采用MPP水準擴充架構的分布式資料庫。ADB PG執行個體由一個或多個協調節點(Master)和多個計算節點(Compute Node)組成，協調節點負責接收使用者請求，制定分布式執行計劃并下發至計算節點，收集執行結果并傳回給用戶端；計算節點負責并行計算分析與資料存儲。資料在計算節點之間可以随機、哈希、複制分布。下圖ADB PG的架構圖:
ADB PG的實體備份恢複功能，基于叢集的基礎備份和日志備份，可以在分布式資料庫繼續提供服務的同時備份各個節點的資料，并保證資料的一緻性。在需要時，可以将分布式資料庫恢複至備份的時刻。
基礎備份是指對資料庫所有資料進行的一個完全拷貝。基礎備份會将叢集全量資料快照壓縮後存儲在其它離線存儲媒體，叢集在基礎備份期間不會阻塞使用者的讀寫，是以，備份期間産生的日志也會被備份來保證基礎備份的完整性。
日志備份(也稱為增量備份)，是指将叢集産生的日志檔案備份至其他離線存儲媒體。日志檔案記錄了使用者對資料庫的DML與DDL操作。通過一個完整的基礎備份以及連續的日志備份，可以将新叢集恢複到某一曆史事件點，保證了這段時間的資料安全性。
ADB PG可保障最小RPO為10分鐘的備份恢複。
三、原理
在完整地介紹ADB PG的備份恢複原理之前，先簡要地介紹單機PG的PITR(Point in Time Recovery)備份恢複機制。ADB PG的備份恢複機制基于單機PG的PITR原理，并加入了分布式資料一緻性的保障機制。
（一）單機PG的PITR機制
WAL日志：
PostgreSQL資料庫會将事務對資料的所有更改(包括DDL、DML等操作)記錄在WAL(Write Ahead Log)日志檔案中。WAL日志檔案可以看作是一個無限增長的隻追加檔案，PG會将日志資料按固定大小切分成多個檔案存儲。事務的每次修改資料的操作都會被追加記錄至WAL檔案中，并賦予一個唯一的LSN序号(Log Sequence Number)，在事務送出時，會保證WAL日志已持久化。
這些日志檔案的作用是為了讓資料庫在需要恢複時，可以通過“重放”WAL日志來恢複資料庫崩潰時還未持久化，但對應事務已送出的資料。
恢複點：
有了WAL日志可以進行“重放”操作，那麼還有一個問題：需要重放到什麼時候呢？這就需要恢複點(restore point)來解決。
恢複點相當于WAL日志中寫入的一個标記，它标記了一個日志的位置。當PG對日志進行重放時，通過檢查是否已經到達這個标記點，來決定是否需要停止"重放"的操作。
以下SQL可以在WAL日志檔案中建立一個名為t1的标志點：
postgres=# select pg_create_restore_point('t1');
LOG: restore point "t1" created at 0/2205780
STATEMENT: select pg_create_restore_point('t1');
pg_create_restore_point
-------------------------
0/2205780
(1 row) 當資料庫順序回放WAL日志時，會檢查目前日志包含此恢複點名稱，若已包含，則停止重放。另外，PG還支援恢複至指定的任意時間點，事務号，LSN序号等操作。
基礎備份與增量備份：
基礎備份是對資料庫資料的一份完整拷貝。可以使用pg_basebackup工具對單機PG進行一次基礎備份，備份資料可儲存至本地，也可存儲在其他離線存儲媒體(OSS)中。
$ pg_basebackup -D pg_data_dir/ -p 6000
NOTICE: pg_stop_backup complete, all required WAL segments have been a 增量備份是指對産生的WAL日志檔案進行備份。在PG中，可通過資料庫參數archive_command來指定如何備份WAL日志資料。當PG生成一個WAL日志檔案時，會通過執行archive_command的指令來嘗試備份歸檔該日志檔案。比如，如下指令會将日志檔案發送至指定的OSS。
archive_command="ossutil cp %p oss://bucket/path/%f" 
單機PG的全量備份與增量備份
需要注意的是，基礎備份期間并不會阻塞資料庫的讀寫，是以備份期間的資料更新對應的WAL日志也需要備份，以備恢複時保證資料的一緻性。
PITR恢複：
當需要恢複資料庫時，首先下載下傳基礎備份資料，然後使用基礎備份開啟叢集，再下載下傳日志檔案備份，“重放”至指定的恢複點即可進行資料庫的恢複。在單機PG中, 指定的恢複點的目标可以是事務号、時間戳、WAL序号(LSN)以及某個恢複點名稱。
（二）ADB PG的分布式一緻性備份恢複機制
ADB PG 作為分布式資料庫，使用兩階段事務送出來管理分布式事務。如果照搬單機PG的PITR機制，會造成資料的不一緻。比如如下場景：分布式事務按照A、B、C時間順序配置設定，但由于種種原因（如網絡延時、節點負載、顯式送出等），分布式模式下事務的送出的順序在各個節點可能各不相同，如下圖所示：
- Master 按照 A、B、C順序送出
- Compute Node 1 按照 A、C、B順序送出
- Compute Node 2 按照 B、C、A順序送出
如果在此過程中，建立了恢複點，當恢複時如果指定恢複至該恢複點，顯而易見，恢複後叢集中各個節點所處的狀态是不一緻的。
兩階段事務送出鎖與一緻性恢複點：
為了解決上述的問題，我們引入了兩階段事務送出鎖。分布式事務送出會以SHARED模式獲得該鎖，而建立恢複點都需要以EXCLUSIVE模式獲得該鎖。于是在叢集中如果有分布式事務正在等待各個節點上送出，那麼叢集建立恢複點的動作必須等待所有節點上的分布式事務送出完後，才能進行。
這從根本上解決了上述這就解決了在分布式事務還在送出的同時建立恢複點而造成恢複時資料不一緻的問題。引入了兩階段送出鎖機制之後，我們可以保證建立的恢複點所對應的各節點狀态是一緻的，是以我們将ADB PG中建立的恢複點稱為一緻性恢複點。
分布式備份與恢複過程：
有了事務送出鎖與一緻性恢複點之後，我們就可以放心地對ADB PG各個節點進行備份和建立一緻性恢複點，而無需擔心節點狀态不一緻的問題。
ADB PG的備份也分為基礎備份和日志備份(也稱為增量備份)。基礎備份是對叢集每個節點進行的一次完整拷貝，ADB PG會對計算節點和協調節點并發地進行備份，将備份資料流式儲存至離線存儲(如OSS)。在進行基礎備份的期間，不會阻塞叢集的讀寫服務。是以，如果在基礎備份期間，使用者有寫入和更新的資料，也需要将資料更改對應的WAL日志進行備份。如下圖所示， ADB PG會對每個節點并行地進行一次資料拷貝，将資料流式上傳至OSS。
ADB PG基礎備份過程
ADB PG的日志備份是對叢集中的計算節點和協調節點産生的WAL日志的備份。各個節點會将自己生成的WAL日志轉儲至離線存儲(如OSS)。同時，叢集會定時地建立一緻性恢複點，并将包含一緻性恢複點的WAL日志進行備份。
當需要恢複新的叢集時，需要同時使用基礎備份與日志備份，并首先建立一個節點數和原執行個體相同的恢複執行個體。各個節點并行拉取指定的基礎備份至本地。之後，每個節點自己拉取自己所需的WAL日志備份檔案，在本地重放，直到重放至指定的一緻性恢複點而停止。最終，我們就能得到一個新的叢集，并保證資料和狀态與源執行個體在一緻性恢複點對應的資料與狀态一緻。恢複的過程如下圖所示：
四、使用
（1）控制台備份相關資訊
- 檢視基礎備份集
使用者在執行個體控制台的“備份恢複”頁面，可以檢視資料庫的基礎備份資料。目前基礎備份資料儲存在OSS上，預設保留天數為7天。
表格中每一行表示一份基礎備份資料，并記錄了備份的開始時間，結束時間，備份狀态(成功/失敗)，備份資料大小以及一緻性時間點。一緻性時間點表示此基礎備份資料可以将叢集恢複至該曆史時間點，并使資料庫處于一緻性狀态。
- 檢視一緻性恢複點
一緻性恢複點是指叢集可以恢複到的某個曆史時間點。使用者在備份恢複頁面的“恢複點”頁可以檢視目前執行個體的所有恢複點。
表格中每一行表示一個一緻性恢複點，并記錄了恢複點的時間戳，表示該恢複點可以讓叢集恢複至此曆史時間點。
檢視日志檔案清單
日志檔案記錄了資料庫的所有更改，在叢集恢複時會使用相應的日志檔案将叢集恢複至一緻性狀态，目前使用者叢集恢複的日志檔案都儲存在OSS上。使用者在備份恢複頁面的"日志備份"中可檢視日志檔案清單。
- 檢視備份政策
備份政策是指執行個體進行備份的周期與時間段，建立一緻性恢複點的頻率，以及資料備份的保留天數等等。
使用者可在備份恢複的“備份設定”中檢視和修改備份政策。
- 修改備份政策
點選“修改備份配置”按鈕，可以對備份政策進行修改。
（2）執行個體恢複步驟
首先檢視源執行個體上的資料
- 進入恢複頁面
使用者可以在控制台的執行個體清單，資料備份清單或恢複點清單點選恢複進入執行個體恢複頁面；
恢複頁面如下：
恢複執行個體的售賣頁面與購買執行個體的頁面大體一緻，但多了如下限制:
1.目前恢複執行個體是master數量必須選擇1個
2.選擇的執行個體segment(computer node)數量必須與源執行個體保持一緻
3.選擇的執行個體存儲空間必須大于或等于源執行個體
- 選擇恢複時間點
在恢複頁面的"克隆源備份集"的下拉框中選擇需要恢複執行個體到哪一個曆史時間點，即指定一個一緻性恢複點。
- 點選購買
使用者點選購買後，與購買新執行個體的流程一樣，需要等待執行個體建立完成後，可在控制台看到新恢複出的執行個體。
- 恢複的新執行個體
檢視恢複的新執行個體上的資料，可以看到資料與源執行個體完全一緻。
五、總結
備份恢複對ADB PG保障資料安全的具有很重要的價值。目前備份恢複功能已經應用多個使用者場景，并保障了最少為10分鐘的RPO。未來ADB PG備份恢複功能會繼續優化備份恢複性能，支援差異化備份，支援更多的存儲媒體，提高使用者使用體驗，為使用者提供更多的功能、性能和成本優化。
相關閱讀：
阿裡最強offer｜神秘的“阿裡星”是一群怎麼樣的人 數瀾科技全面內建阿裡雲AnalyticDB資料倉庫 打造輕量級資料中台 對話李飛飛，揭秘國際體育賽事風“雲”背後的黑科技 第三屆資料庫大賽創新上雲性能挑戰賽