PostgreSQL的流复制（Streaming Replication）是构建高可用和读写分离架构的核心机制。主库不断产生WAL（预写日志），备库通过网络实时接收并回放这些日志。当主备之间隔着公网或跨机房专线时，网络带宽往往成为瓶颈，WAL传输会挤占业务流量，甚至导致复制延迟不断增大。针对这种情况，PostgreSQL提供了流复制的压缩传输能力，可以在传输前对WAL数据压缩，显著降低网络开销。这篇文章就来详细讲清楚压缩传输的配置方法、原理机制以及使用中的注意事项。
一、流复制压缩的两种实现层面
PostgreSQL中与流复制压缩相关的机制主要有两个层面，很多人容易把它们混为一谈。第一个层面是备库端通过libpq连接参数启用WAL流的压缩，也就是在primary_conninfo中添加压缩相关参数。第二个层面是主库端的wal_compression参数，它控制的是WAL写入磁盘前是否压缩WAL记录中的全页镜像（Full Page Image）。
两者的作用点完全不同。libpq层面的压缩作用于网络传输过程，WAL文件在发送前压缩、接收后解压，落盘的数据不受影响；而wal_compression>作用于WAL的物理存储，压缩的是日志内容本身，传输的字节自然也会变少，但这是以主库额外的CPU消耗为代价的。如果你的目标是纯粹的省带宽，优先考虑libpq层面的压缩。
二、配置方法与参数详解
先说传输层压缩的配置。在PostgreSQL 15之前，libpq支持通过compression=1开启简单的zlib压缩。从PostgreSQL 15开始，压缩参数被扩展为更细粒度的形式，可以指定算法和级别，例如compression=zlib:5或compression=zstd:3。备库的配置写在postgresql.conf或postgresql.auto.conf中：
-- 在备库执行，修改后重启或重新加载 ALTER SYSTEM SET primary_conninfo = 'host=192.168.1.10 port=5432 user=replicator password=xxx compression=zstd:3'; SELECT pg_reload_conf();
注意compression是连接串级别的参数，主库端不需要做任何额外设置，只要备库发起的连接请求中带有该参数，主库就会按协商结果压缩发送。zstd算法在压缩比和速度之间的平衡比老的zlib好很多，特别适合WAL这种重复度较高的顺序数据，一般推荐压缩级别设为1到3，级别过高收益递减且CPU开销明显上升。
再看wal_compression参数。PostgreSQL 15之前它是一个布尔值，15之后扩展为支持pglz、lz4、zstd和on（等价于pglz）等取值：
-- 主库端设置，控制WAL中全页镜像的压缩 ALTER SYSTEM SET wal_compression = 'zstd'; SELECT pg_reload_conf();
这个参数的收益场景是频繁全页写（如大批量UPDATE、索引重建）的写密集型业务。WAL体积变小后，不仅传输量下降，磁盘IO和归档存储成本也会降低，可以说是一举多得，但要评估主库CPU是否有富余。
三、如何验证压缩效果与排查常见问题
配置完成后，验证压缩是否生效是关键一步。最直接的方式是观察网络流量，可以在主库上用iftop、nethogs等工具对比开启压缩前后发往备库端口的流量变化，一般能观察到30%到70%的降幅，具体取决于写入模式。也可以通过pg_stat_wal_receiver（备库视图，旧版本叫pg_stat_wal_receiver统计信息）查看接收状态，确认复制延迟没有异常增长。
排查问题时有几个常见坑。第一，版本兼容性：如果备库连接串里写了compression=zstd:3，而主库编译时没有启用zstd支持，连接会直接失败并报出协商错误，此时需要改用双方都支持的算法。第二，版本差异：PostgreSQL 15及以后不再支持旧的compression=1布尔写法对应的某些协商行为，升级后要检查连接串。第三，压缩会占用备库的CPU用于解压，如果备库本身回放压力就大，启用压缩前先看CPU余量。
还有一个实践建议：压缩级别不是越高越好。WAL是持续产生的流式数据，压缩级别过高会增加主库发送端的延迟，反而可能拖慢复制。生产环境建议从最低级别开始测试，逐步观察带宽降幅与CPU占比，找到性价比最高的平衡点。对于内网万兆环境下的主备架构，通常不需要启用压缩，因为带宽充裕时压缩的CPU代价比省下的带宽更贵；而跨机房专线带宽受限、通过公网VPN同步、或者需要容灾到远端的场景，压缩传输的收益非常明显。
总结一下，PostgreSQL流复制的压缩传输配置简单、见效直接，核心是理解libpq连接串压缩和wal_compression两个层面各自的作用范围，再结合自身网络条件与CPU资源选择合适的算法和级别。合理的压缩策略能让低带宽环境下的主从同步保持低延迟，为高可用架构打下坚实基础。
PostgreSQL流复制压缩传输修改时间：2026-09-13 15:20:41