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/archchown -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]# ls000000020000000000000003 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/arch
4.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_bak
5.基于时点恢复
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 0000000400000000000000DAmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/DA000028, prev 0/D9000100, desc: RUNNING_XACTS nextXid 2173559 latestCompletedXid 2173558 oldestRunningXid 2173559rmgr: 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 FPWrmgr: Transaction len (rec/tot): 34/ 34, tx: 2173559, lsn: 0/DA0000F8, prev 0/DA000060, desc: COMMIT 2022-02-21 17:40:31.486619 HKTrmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/DA000120, prev 0/DA0000F8, desc: RUNNING_XACTS nextXid 2173560 latestCompletedXid 2173559 oldestRunningXid 2173560rmgr: 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