WAL（Write-Ahead Logging）是PostgreSQL保证数据一致性的核心机制，开启归档模式后，每个生成的WAL段文件都会被复制到归档目录长期保存，用于支持时间点恢复（PITR）和物理备库。但很多团队在运行一段时间后发现，归档目录的增长速度远超预期：一个写入频繁的数据库，每天产生的WAL文件动辄几十GB，一个月下来就是TB级别的存储开销。这些文件本质上是二进制日志，压缩率非常高，直接原样保存其实是一种浪费。本文围绕归档日志的压缩存储展开，从原生配置、工具选型到恢复注意事项，给出完整可落地的方案。
一、使用archive_command配合压缩工具实现落盘即压缩
最直接的方案是在归档命令中嵌入压缩工具。PostgreSQL通过archive_command参数调用外部命令，只要命令返回0即认为归档成功，因此可以在命令里串联gzip、zstd等压缩程序。以下是一个典型的postgresql.conf配置：
# 开启归档 archive_mode = on archive_command = 'zstd -z -q -3 %p > /data/pg_archive/%f.zst' # %p 代表WAL段文件的完整路径 # %f 代表文件名，如 000000010000000000000001
这个配置的关键点在于：压缩后的文件名要保证唯一性，直接在原名后追加后缀即可。zstd是当前比较推荐的选择，它压缩速度快、支持多线程，解压速度也远超gzip，尤其适合写入量大的场景。如果系统里没有zstd，也可以用gzip替代，命令写法为gzip -c %p > /data/pg_archive/%f.gz。
需要特别注意的是，archive_command执行的命令是逐个文件同步调用的，如果压缩耗时超过WAL产生的速度，归档会延迟堆积。因此压缩级别不宜设得过高，zstd的-3是速度和压缩比的平衡点，追求极限压缩可以到-9，但要评估归档是否跟得上。另外建议在归档目录上配置监控，观察pg_stat_archiver视图中的failed_count，确保归档持续成功。
压缩率方面，WAL文件的实际压缩效果和写入模式有关。大量顺序插入产生的WAL压缩后通常只有原大小的10%到15%，而包含大量索引更新的场景压缩后约为20%到30%。总体来看，16MB的段文件压缩后一般在2MB到4MB之间，长期保存的存储成本大幅下降。
二、用pgbackrest等备份工具管理压缩归档
如果服务器数量较多，手动维护压缩脚本会变得繁琐，此时更推荐使用专业备份工具。pgbackrest内置了归档管理能力，压缩、校验、过期清理一条龙完成，是目前社区认可度最高的方案之一。它的配置示例如下：
# /etc/pgbackrest/pgbackrest.conf [global] repo1-path=/data/pgbackrest repo1-retention-full=2 repo1-cipher-type=aes-256-cbc compress-type=zst compress-level=3 process-max=4 [main] pg1-path=/data/pgdata/16/main
同时在postgresql.conf中把归档命令改为pgbackrest提供的接口：
archive_mode = on archive_command = 'pgbackrest --stanza=main archive-push %p'
pgbackrest的优势在于压缩之外还提供了分层保留策略，可以按全量备份加增量的方式管理归档链，配合repo1-retention-full自动清理过期归档，避免人工删除时误删仍被备份依赖的WAL文件。它的并行处理能力（process-max）也能显著提升归档吞吐，写入高峰期不容易积压。
除了pgbackrest，barman也是常见的选择，它支持gzip压缩和网络归档到远程服务器，适合有异地容灾需求的架构。两者功能上大同小异，选型时可以优先看团队已有的运维体系和熟悉程度。无论选哪个工具，都比裸脚本多了完整性校验和恢复流程保障，生产环境建议优先考虑。
三、恢复时的解压处理与常见坑
压缩存储的最大顾虑是恢复链路是否顺畅。使用recovery时，PostgreSQL需要通过restore_command获取WAL文件，由于归档是压缩格式，恢复命令中必须加入解压环节。以zstd为例：
# recovery配置（PostgreSQL 12及以上写在 postgresql.conf 或通过 restore_command 传递） restore_command = 'zstd -d -q /data/pg_archive/%f.zst > %p'
pgbackrest则无需手动写解压命令，直接使用pgbackrest --stanza=main restore即可自动完成压缩归档的提取和恢复。这也是使用工具方案的额外好处，恢复流程标准化，出故障时不容易手忙脚乱。
这里有几个容易踩的坑值得提醒。第一，restore_command在目标文件不存在时必须返回非零值，PostgreSQL依赖这个返回码判断WAL是否结束，压缩工具在输入文件缺失时的行为要提前验证。第二，如果归档目录同时在主库和备库之间通过restore_command共享，注意压缩格式的一致性，混用gzip和zstd后缀会导致恢复失败。第三，切换压缩方案时存在过渡期，新旧格式并存的情况下，恢复脚本要能同时处理两种后缀，可以写一个小的wrapper脚本做兼容判断。
最后从源头看，归档量也可以主动控制。检查wal_level是否过度配置（logical比replica产生更多WAL），评估wal_compression参数是否开启，PostgreSQL 15之后该参数支持设置压缩算法，能在生成WAL时就压缩全页镜像，从写入端减小日志体积。合理的参数加上落盘压缩，双管齐下才能真正把归档存储控制在合理范围内。
PostgreSQL归档日志压缩WAL归档修改时间：2026-09-08 22:51:06