​簡介：本文將介紹AnalyticDB PostgreSQL版備份恢復的原理與使用方法。

一、背景

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備份恢復功能會繼續優化備份恢復效能，支援差異化備份，支援更多的儲存介質，提高使用者使用體驗，為使用者提供更多的功能、效能和成本優化。

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​