簡介：本文將介紹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備份恢復功能會繼續優化備份恢復性能，支持差異化備份，支持更多的存儲介質，提高用戶使用體驗，為用戶提供更多的功能、性能和成本優化。

相關閱讀：

阿里最強offer｜神秘的“阿里星”是一群怎么樣的人

數瀾科技全面集成阿里云AnalyticDB數據倉庫 打造輕量級數據中臺

對話李飛飛，揭秘國際體育賽事風“云”背后的黑科技

第三屆數據庫大賽創新上云性能挑戰賽

原文鏈接：https://developer.aliyun.com/article/786487?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的数据库误操作后悔药来了：AnalyticDB PostgreSQL教你实现分布式一致性备份恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。