PostgerSQL 14-17备份的变化 PG17更贴近商业数据库 与 实际命令

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满  9群 为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

最近周六上课有同学问，PG的高版本在备份上有什么优势，今天我们总结一篇PG的高低版本的备份方式的差异性。

版本以PG14 和  PG17作为两个版本的差异性分析，PG18暂时不考虑进行推荐，主要还是密码加密方式抛弃了MD5导致一些开源的软件有可能不支持新的密码加密方式而导致无法兼容新版本导致的，而最近AI的冲击，有一些PG开源软件很可能会停止开发，所以如果以企业稳定性为主，建议还是PG17先作为企业的PG所选的版本。

同时PG软件版本更新较快，一些功能迭代快，也被人吐槽，软件的兼容性应该考虑，这点不知可否，开源软件你还要什么自行车。

我们先比对两个版本的区别

1 备份的方式，在PG14中我们仅仅支持全量物理备份，无论你是用pg_basebackup,还是手动用 pg_start_backup/pg_stop_backup 等，都是没有原生的增量备份能力。

PG17 是具备增量备份的机制的，在我们使用pg_basebackup 命令里面带有了--incremental 参数，给予一个已经有的全备是可以生成增量备份的。

同时还有一个新的工具，pg_combinebackup用于将全量和增量进行合并增量的备份给予wal记录和页级校验，

所以PG17让PG的备份更加的商业化，这点要点赞。

2 备份压缩的问题

备份中进行数据压缩是一个核心的数据库备份应该具有的功能，当然MYSQL是没有这个功能的PG在14之前都是没有的，和MYSQL一个战线，而PG15后，PG支持了服务器端的压缩算法，也就是不再需要客户端数据流进行数据的备份压缩，而是通过服务端进行数据的压缩了。参数中会添加 --compress=server的方式来进行服务器端的备份进行数据压缩。

同时压缩的算法从 GZIP扩展到了 LZ4 ZSTD 等多种方案。

这里主要是PG14是通过pg_receivewal 来进行复制协议，不支持压缩传输，PG15以上的是通过wal_compression 来进行的压缩方式的数据发送。

对于我们使用的传统的工具pg_dump来说，相关的备份差别在如下方面

PostgreSQL 14并行备份（-j）可用，但每个 worker 独立生成数据，压缩方式单一。不支持对分区表的并行优化。

PostgreSQL 15–17

15 起支持多种压缩算法（见上文）。

16 改进了并行备份对分区表的处理，允许每个分区作为独立单元并行导出。

17 进一步优化了大型数据库的并行备份内存管理，减少临时文件占用。

而对于pg_receivewal和pg_verifybackup的改进也是很明显的，PostgreSQL 14，pg_receivewal 仅支持将 WAL 流式写入本地文件，无压缩。PostgreSQL 15+，新增 --compress 选项，支持 gzip、LZ4、zstd 压缩，减少归档存储空间。PostgreSQL 17，压缩选项与 --no-sync 等参数配合更稳定，并支持在压缩时进行校验。

PostgreSQL 14，已有 pg_verifybackup，但功能较基础，主要验证备份清单中的文件是否存在且校验和正确。

PostgreSQL 15–17

15 增加了 --progress 选项显示验证进度。

16 支持验证备份中 WAL 的完整性。

17 支持验证增量备份合并后的结果，并能更精确地报告错误位置

所以从备份的角度来说PG17是一个在备份方面升级的好的选择。

下面我们用一组备份中的版本命令的差异来说明备份的具体的差异

1  PostgreSQL14 全量备份与带压缩的全量备份

# 最基础的全量备份
pg_basebackup -h localhost -U repl_user -D /backup/full_backup -Fp -Xs -P

# 带客户端 gzip 压缩（CPU 在客户端）
pg_basebackup -h localhost -U repl_user -D - -Fp -Xs -P | gzip > /backup/base.tar.gz

2 PostgreSQL 17 的备份

# 1. 先做一次全量备份（必须开启 summarize_wal）
pg_basebackup -h localhost -U repl_user \
  -D /backup/full_backup \
  --compress=server-zstd:5 \
  -Fp -Xs -P

# 2. 基于全量做增量备份
pg_basebackup -h localhost -U repl_user \
  --incremental=/backup/full_backup/backup_manifest \
  -D /backup/incr_backup_$(date +%Y%m%d) \
  --compress=server-zstd:5 \
  -Fp -Xs -P

这里差异最大的是备份的增量的工作的完成，如果PG14则不支持通过全量后基于全量的增量的数据库备份。 PG17完全支持通过全部且压缩的场景下，继续进行指定上一次增量备份后的增量备份。

在数据库恢复的情况下，PG17支持全量+增量的数据库恢复的模式，这里需要注意指定的增量的文件必须是有顺序的

# 合并全量 + 两个增量，输出到恢复目录
pg_combinebackup \
/backup/full_backup \
/backup/incr_backup_20240101 \
/backup/incr_backup_20240102 \
-o /var/lib/postgresql/17/data_recovery

同样的情况，postgresql 17的不少命令都支持压缩的功能，如下

# 仅支持无压缩的 WAL 流式接收
pg_receivewal -h localhost -U repl_user -D /archive/wal/ --slot=my_slot

# 支持流式压缩归档
pg_receivewal -h localhost -U repl_user -D /archive/wal/ \
  --compress=lz4 \
  --slot=my_slot

# 或 zstd 压缩
pg_receivewal --compress=zstd:3 -D /archive/wal/

最后，PG17增量的备份中支持需要提前开启参数， -- PG17 必需

ALTER SYSTEM SET summarize_wal = on;

SELECT pg_reload_conf();

PG17 在备份领域的升级，补齐了 PostgreSQL 长期以来被诟病的"企业级备份能力短板"。虽然 pgBackRest、Barman 等第三方工具依然优秀，但原生能力的完善意味着更低的运维复杂度、更少的依赖风险，尤其在当前开源软件维护不确定性增加的背景下，减少外部依赖本身就是一种稳健策略。