1. pg_basebackup 簡介
是從postgresql 9.1版本開始提供的一個方便基礎備份的工具
pg_basebackup用於對正在運行的PostgreSQL數據庫集群進行基本備份。備份是在不影響數據庫的其他客戶端的情況下進行的，並且可以用於時間點恢復和作為日志傳送或流復制備用服務器的起點 。
pg_basebackup 不僅可以從主服務器也可以從備用服務器進行基本備份。要從備用數據庫進行備份，請設置備用數據庫以便它可以接受復制連接（即 setmax_wal_senders和hot_standby，並對其進行pg_hba.conf適當配置）。您還需要在主節點上啟用full_page_writes。
1.1 優點
a. 可以遠程備份， 通過日志可以恢復到最新
b. 可以通過備庫備份
c. 備份操作相關簡單
1.2 不足
a. 它只把整個數據庫實例的數據都拷貝出來，而不只是把實例中的部分（如某個數據庫或表）單獨備份
b. 歸檔日志需要單獨備份
c. 使用復制協議 REPLICATION權限或者是超級用戶的用戶 ID 建立連接，並且pg_hba.conf必須允許復制連接。
d.服務器還必須配置max_wal_senders設置得足夠高，以提供至少一個用於備份的 walsender 和一個用於 WAL 流式傳輸（如果使用）。
e.如果在備份期間將備用數據庫提升為主數據庫，則備份將失敗。
1.3工作原理
1）創建檢查點，打開FPW (full-page-write) ，創建備份標簽（存儲檢查點位置，時間等信息）
2）通過流復制協議與數據庫建立連接，主庫的WAL Sender進程向pg_basebackup發送數據庫物理文件
3）pg_basebackup接收到文件后寫入目標位置（壓縮或不壓縮）
2.pg_basebackup參數說明
查看幫助文檔 pg_basebackup --help
postgres@s2ahumysqlpg01-> pg_basebackup --help
用法：
pg_basebackup [選項] ...
控制輸出的選項：
-D, --pgdata=DIRECTORY 接收基本備份到目錄
-F, --format=p|t 輸出格式（plain（默認），tar）
-r, --max-rate=RATE 傳輸數據目錄的最大傳輸速率（以 kB/s 為單位，或使用后綴“k”或“M”）
-R, --write-recovery-conf 用於復制的寫入配置
-T, --tablespace-mapping=OLDDIR=NEWDIR 將 OLDDIR 中的表空間重定位到 NEWDIR
--waldir=WALDIR 預寫日志目錄的位置
-X, --wal-method=none|fetch|stream 包含指定方法所需的 WAL 文件
-z, --gzip 壓縮 tar 輸出
-Z, --compress=0-9 使用給定的壓縮級別壓縮 tar 輸出
常規選項：
-c, --checkpoint=fast|spread 設置快速或擴展檢查點
-C, --create-slot 創建復制槽
-l, --label=LABEL 設置備份標簽
-n, --no-clean 出錯后不清理
-N, --no-sync 不等待更改安全寫入磁盤
-P, --progress 顯示進度信息
-S, --slot=SLOTNAME 要使用的復制槽
-v, --verbose 輸出詳細信息
-V, --version 輸出版本信息，然后退出
--no-slot 防止創建臨時復制槽
--no-verify-checksums 不驗證校驗和
-?, --help 顯示此幫助，然后退出
連接選項：
-d, --dbname=CONNSTR 連接字符串
-h, --host=HOSTNAME 數據庫服務器主機或套接字目錄
-p, --port=PORT 數據庫服務器端口號
-s, --status-interval=狀態包發送到服務器的間隔時間（以秒為單位）
-U, --username=NAME 以指定的數據庫用戶連接
-w, --no-password 從不提示輸入密碼
-W, --password 強制密碼提示（應該自動3.pg_basebackup 備份示例
3.1. 開啟歸檔
創建歸檔目錄
mkdir -p /ssd/pg957/arch
chown -R postgres:postgres /ssd/pg957/arch
配置歸檔命令
vi $PGDATA/postgresql.conf
archive_mode = on
archive_command = 'DATE=`date +%Y%m%d`; DIR="/ssd/pg957/arch/$DATE"; (test -d $DIR || mkdir -p $DIR) && cp %p $DIR/%f'
wal_level = hot_standby #備注說明
注釋：
%p 表示xlog文件名$PGDATA的相對路徑, 如pg_xlog/00000001000000190000007D
%f 表示xlog文件名, 如00000001000000190000007D
備注：
wal_level：指定生成wal日志的級別，值為minmal，archive，hot_standby。
minmal一般的配置，archive會生成wal歸檔需要的日志記錄，hot_standby添加備庫時需要設置。 3.2. 重啟並驗證歸檔
重啟數據庫使參數生效，驗證歸檔。
checkpoint; # 解釋checkpoint做了什么
select pg_switch_wal() ; # 10g 以前用 select pg_switch_xlog();
[root@hgdb01 20180117]# pwd
/ssd/pg957/arch/20180117
[root@hgdb01 20180117]# ls
000000020000000000000003 000000020000000000000004
3.3. 創建replication權限的角色
創建replication權限的角色, 或者超級用戶的角色。
create role repl nosuperuser replication login connection limit 32 encrypted password '111111';
3.4. 配置pg_hba.conf
配置pg_hba.conf，添加以下內容
host replication repl 0.0.0.0/0 md5
3.5. 執行備份
#因為使用流復制協議, 所以支持異地備份
pg_ctl reload #執行加載配置的命令
mkdir `date +%F` ;
pg_basebackup -F t -x -D /home/postgres/bak/`date +%F` -h 192.168.137.220 -p 5432 -U repl
V12：
pg_basebackup -F t -X s -D /home/postgres/bak/`date +%F` -h 192.168.137.220 -p 5432 -U repl
3.6. 備份檢查
備份完畢，查看備份文件
[postgres@hgdb01 ~]$ cd /dbbak/2018-01-17
[postgres@hgdb01 2018-01-17]$ ll
total 46M
-rw-rw-r--. 1 postgres postgres 1.5K Jan 17 01:13 16400.tar
-rw-rw-r--. 1 postgres postgres 46M Jan 17 01:13 base.tar
[postgres@hgdb01 2018-01-17]$ tar -tvf base.tar |less #查看備份包內容
3.7. 注意事項
pg_basebackup 備份參數 -F -t -X
-F 指定了輸出的格式，支持p（原樣輸出）或者t（tar格式輸出）。
-X 表示備份開始后，啟動另一個流復制連接從主庫接收WAL日志。
16400表空間的oid
簡單講述表空間的軟連接
[postgres@hgdb01 pg_tblspc]$ ls -l
total 0
lrwxrwxrwx. 1 postgres postgres 14 Jan 17 01:04 16400 -> /pgtbls/tbls01
4.pg_basebackup 恢復過程
4.1 切換日志
在需要備份的庫中創建標記表，並檢查點和歸檔指令
create table t_flag(id int) ;
insert into t_flag values(1);
checkpoint; #刷新內存臟頁到磁盤
select pg_switch_wal(); #手動日志歸檔4.2 刪除原數據
停止數據庫並刪除數據目錄，將pg_basebackup生成的備份包分別解壓到相應目錄
pg_ctl stop -D /u01/postgresql/data_bak
清空 data_bak 里的文件
rm -rf /u01/postgresql/data_bak/*
#解決備份文件到指定目錄
tar -xvf base.tar.gz -C /u01/postgresql/data_bak/
# 如果歸檔文件存在可以直接用歸檔文件
tar -xvf pg_wal.tar.gz -C /u01/postgresql/arch4.3 恢復參數
pg12以前
在PG12以前需要修改 recovery.conf文件配置還原參數
PGHOME/share/recovery.conf.sample
PGDATA/recovery.conf #備注
restore_command = 'cp /ssd/pg957/arch/20180118/%f %p'
recovery_target_timeline = 'latest'
備注1：配置recovery_target_timeline參數, 便於判斷是否已經到達還原點. (可選, 僅做PITR時需要.一般都是恢復到最新)
備注2：對路徑 /ssd/pg957/arch/20180118/的解釋
備注3：備份完成后recovery.conf文件名會自動修改為 recovery.done
pg12以后
從v12開始，針對此問題進行了改進，把recovery.conf中的參數合到了postgresql.conf配置文件中，但在非恢復模式這些參數將被忽略。
從PG12開始，recovery.conf文件不存在，由下面兩個新文件進行替換：
recovery.signal：告訴PostgreSQL進入正常的歸檔恢復
standby.signal：告訴PostgreSQL進入standby模式
如果兩個文件都存在，則standby.signal優先。
export PGDATA=/u01/postgresql/data_bak
# 告訴PostgreSQL進入正常的歸檔恢復
touch $PGDATA/recovery.signal
echo "
restore_command = 'cp /u01/postgresql/arch/%f %p'
recovery_target = 'immediate'
" >> $PGDATA/postgresql.auto.conf
4.4 啟動驗證
啟動數據庫並做數據查看驗證是否恢復完成
pg_ctl start -D /u01/postgresql/data_bak5.基於時點恢復
5.1 恢復目標
默認情況下，恢復將恢復到 WAL 日志的末尾即，備份那一刻的日志。即recovery_target默認為immediate。
以下參數可用於指定較早的停止點。最多可以使用recovery_target
, recovery_target_lsn
, recovery_target_name
, recovery_target_time
, or之一；recovery_target_xid
如果在配置文件中指定了其中一個以上，則會引發錯誤。這些參數只能在服務器啟動時設置。https://www.postgresql.org/docs/14/runtime-config-wal.html
recovery_target = ’immediate’指定恢復應該在達到一個一致狀態后盡快結束，即盡早結束。 在從一個在線備份中恢復時，這意味着備份結束的那個點。
recovery_target_name (string)指定恢復將繼續進行的已命名的恢復點 （pg_create_restore_point()創建）。
recovery_target_time (timestamp)這個參數指定恢復將繼續執行的時間戳。精確的停止點也受到recovery_target_inclusive的影響。
recovery_target_xid (string)指定恢復將繼續執行的事務ID。
recovery_target_inclusive (boolean)指定我們是否在指定的恢復目標之后停止（true）， 或者在恢復目標之前停止（false）。
recovery_target_timeline (string)指定恢復到一個特定的時間線中。默認值是沿着基礎備份建立時的當前時間線恢復。
將這個參數設置為latest會恢復到該歸檔中能找到的最新的時間線， 這在一個后備服務器中有用。
recovery_target_action (enum) (boolean)指定當到達恢復目標時服務器應該采取什么動作。默認值是pause， 這意味着將暫停恢復。
promote意味着將結束恢復進程並且服務器開始接受連接。 shutdown將在到達恢復目標后停止服務器。
5.2 示例
基於時間點注意事項：
1. 歸檔日志完整
2. 指定從歸檔目錄萬利 restore_command = 'cp /u01/postgresql/arch/%f %p'
3.設置recovery_target_time 或 recovery_target_lsn 或 recovery_target_xid
4.創建touch $PGDATA/recovery.signal
#示例：
#設置基於時間的恢復
recovery_target_time = '2022-02-07 13:45:00+08'
#設置基於lsn,或 xid 的恢復
recovery_target_lsn 或 recovery_target_xid 可以通過pg_waldump 解析日志，來確定恢復目標
如本例需要恢復到COMMIT 可以設置 xid 為 '34' 或 lsn 為 '0/DA0000F8'
recovery_target_xid='34' 或 recovery_target_lsn='0/DA0000F8'
postgres@s2ahumysqlpg01-> pg_waldump 0000000400000000000000DA
mgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/DA000028, prev 0/D9000100, desc: RUNNING_XACTS nextXid 2173559 latestCompletedXid 2173558 oldestRunningXid 2173559
rmgr: Heap len (rec/tot): 54/ 150, tx: 2173559, lsn: 0/DA000060, prev 0/DA000028, desc: INSERT off 2 flags 0x00, blkref #0: rel 1663/13548/34369 blk 0 FPW
rmgr: Transaction len (rec/tot): 34/ 34, tx: 2173559, lsn: 0/DA0000F8, prev 0/DA000060, desc: COMMIT 2022-02-21 17:40:31.486619 HKT
rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/DA000120, prev 0/DA0000F8, desc: RUNNING_XACTS nextXid 2173560 latestCompletedXid 2173559 oldestRunningXid 2173560
rmgr: XLOG len (rec/tot): 24/ 24, tx: 0, lsn: 0/DA000158, prev 0/DA000120, desc: SWITCH 5.3 恢復控制
pg_is_wal_replay_paused() →boolean 如果請求恢復暫停，則返回 true。
pg_get_wal_replay_pause_state() →text 返回恢復暫停狀態。返回值是not paused是否未請求pause requested暫停，是否請求暫停但恢復尚未暫停，以及paused恢復是否實際暫停。
pg_promote ( wait boolean DEFAULT true, wait_seconds integer DEFAULT 60 ) → boolean
將備用服務器提升為主狀態。wait如果設置為（默認值），該true函數會等待升級完成或wait_seconds秒數過去，true如果升級成功則返回，false否則返回。如果wait設置為false，則函數在向 postmastertrue發送SIGUSR1信號以觸發提升后立即返回。
默認情況下，此功能僅限超級用戶使用，但可以授予其他用戶 EXECUTE 權限來運行該功能。
pg_wal_replay_pause() →void 請求暫停恢復。請求並不意味着恢復立即停止。如果要保證恢復實際上已暫停，則需要檢查由pg_get_wal_replay_pause_state(). 請注意，pg_is_wal_replay_paused()返回是否發出請求。恢復暫停時，不會應用進一步的數據庫更改。如果熱備用處於活動狀態，所有新查詢將看到相同的數據庫快照，並且在恢復恢復之前不會產生進一步的查詢沖突。
默認情況下，此功能僅限超級用戶使用，但可以授予其他用戶 EXECUTE 權限來運行該功能。
pg_wal_replay_resume() →void 如果已暫停，則重新啟動恢復。 默認情況下，此功能僅限超級用戶使用，但可以授予其他用戶 EXECUTE 權限來運行該功能。
注意：
pg_wal_replay_pause 和 pg_wal_replay_resume不能在提升主庫時進行執行。如果在恢復暫停時觸發了提升，則暫停狀態結束並繼續提升。
5.4 備份進度
在pg 14中備份進行可以通過下面這個視圖查詢
pg_stat_progress_basebackup
6.版本差異
pg12 以前和 pg12 以后部份差異可以參考 ： https://www.modb.pro/db/25236
參考
https://www.modb.pro/db/25236
https://www.postgresql.org/docs/14/runtime-config-wal.html
https://www.postgresql.org/docs/14/functions-admin.html
https://www.postgresql.org/docs/current/progress-reporting.html#BASEBACKUP-PROGRESS-REPORTING