一、pg_basebackup工作原理
1、创建检查点，打开FPW，创建备份标签（存储检查点位置，时间等信息）;
2、通过流复制协议与数据库建立连接，WAL Sender进程向pg_basebackup发送数据库物理文件;
3、pg_basebackup接收到文件后写入目标位置（压缩或不压缩）。
二、pg_basebackup 参数说明
可以通过pg_basebackup --help 详细查看
-h 指定连接的数据库的主机名或IP地址，这里就是主库的ip。
-U 指定连接的用户名，此处是我们刚才创建的专门负责流复制的repl用户。
-F 指定了输出的格式，支持p（原样输出）或者t（tar格式输出）。
-x 表示备份开始后，启动另一个流复制连接从主库接收WAL日志。
-P 表示允许在备份过程中实时的打印备份的进度。
-R 表示会在备份结束后自动生成recovery.conf文件，这样也就避免了手动创建。
-D 指定把备份写到哪个目录，这里尤其要注意一点就是做基础备份之前从库的数据目录（/usr/local/postgresql/data）目录需要手动清空。
-l 表示指定一个备份的标识
三、pg_basebackup 备份过程
1）开启归档
创建归档目录
mkdir -p /data/pg_arch
chown -R postgres:postgres /data/pg_arch
配置归档命令
vi postgresql.conf
archive_mode = on
archive_command = 'DATE=`date +%Y%m%d`; DIR="/data/pg_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添加备库时需要设置。
2）重启数据库使参数生效，验证归档。
checkpoint;
select pg_switch_wal();
如果是PG10 以前用 select pg_switch_xlog();
[root@testdb 20180117]# pwd
/ssd/pg957/arch/20180117
[root@testdb 20180117]# ls
000000020000000000000003 000000020000000000000004
3）创建replication权限的角色,或者超级用户的角色。
create role repl nosuperuser replication login connection limit 32 encrypted password '111111';
4）配置pg_hba.conf，添加以下内容
host replication repl 0.0.0.0/0 md5
5）执行备份（因为使用流复制协议,所以支持异地备份）
执行加载配置的命令
pg_ctl -D /data/pgsql reload
mkdir /data/tmp_backup/`date +%Y%m%d`
pg_basebackup -F t -X -D /data/tmp_backup/`date +%Y%m%d` -h 10.2.29.66 -p 5432 -U repl
PG12：
export PGPASSWORD=111111
pg_basebackup -F t -X s -D /data/tmp_backup/`date +%Y%m%d` -h 10.2.29.66 -p 5432 -U repl
6） 备份检查
[postgres@testdb ~]$ cd /data/tmp_backup/20240426
[postgres@testdb 20240426]$ 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@testdb 20240426]$ tar -tvf base.tar |less
四、基于pg_basebackup热备份的还原过程
1）在需要备份的库中创建标记表，并检查点和归档指令
create table t_flag(id int);
insert into t_flag values(1);
#刷新内存脏页到磁盘
checkpoint;
#手动日志归档
select pg_switch_wal();
2）停止数据库并删除数据
pg_ctl stop -D /data/pgsql/
3）解压备份文件到指定目录
mkdir /data/pgdata_bak
mkdir /data/pgdata_bak_arch
tar -xvf base.tar -C /data/pgdata_bak/
# 如果归档文件存在可以直接用归档文件
tar -xvf pg_wal.tar -C /data/pgdata_bak_arch/
chown -R postgres:postgres /data/pgdata_bak
chown -R postgres:postgres /data/pgdata_bak_arch
4）恢复参数
pg12以前
在PG12以前需要修改 recovery.conf文件配置还原参数
cp $PGHOME/share/recovery.conf.sample $PGDATA/recovery.conf
cat > $PGDATA/recovery.conf << EOF
restore_command = 'cp /data/pg_arch/20180118/%f %p'
recovery_target_timeline = 'latest'
EOF
备注1：配置recovery_target_timeline参数, 便于判断是否已经到达还原点. (可选, 仅做PITR时需要.一般都是恢复到最新)
备注2：对路径 /data/pg_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优先。
su - postgres
export PGDATA=/data/pgdata_bak
touch $PGDATA/recovery.signal
cat > $PGDATA/postgresql.auto.conf << EOF
restore_command = 'cp /data/pg_arch/`date +%Y%m%d`/%f %p'
recovery_target = 'immediate'
EOF
5）启动验证
chmod 750 -R /data/pgdata_bak
pg_ctl -D /data/pgdata_bak -l /data/pgdata_bak/logfile.log start
五、基于时点恢复
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将在到达恢复目标后停止服务器。
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
如果有还原点，也可以恢复到指定的还原点：
创建还原点：
SELECT pg_create_restore_point('restore_point1');
恢复到还原点：
recovery_target_name ='restore_point1'
#示例：
#设置基于时间的恢复
recovery_target_time = '2024-04-26 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
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不能在提升主库时进行执行。如果在恢复暂停时触发了提升，则暂停状态结束并继续提升。
4、备份进度
在pg 14中备份进行可以通过下面这个视图查询
pg_stat_progress_basebackup
六、版本差异
pg12 以前和 pg12 以后部份差异可以参考 ： https://www.modb.pro/db/25236
浙公网安备 33010602011771号