Postgres逻辑复制按发布者/订阅者限制带宽及首次同步限速问题

问题1：是否可在Postgres或操作系统层面，针对逻辑复制的单个发布者/订阅者设置带宽上限？ #

Postgres原生层面 #

目前Postgres官方版本没有内置针对逻辑复制单链路的带宽限流功能，原生提供的wal_sender_timeout、wal_receiver_timeout等参数仅用于复制链路的断链检测，不涉及流量控制。
你可以通过调整参数间接缓解流量峰值：

• 调小logical_decoding_work_mem，减少逻辑解码单次批量发送的WAL数据量
• 写入30MB二进制文件时拆分事务分批次提交，避免一次性推送大量WAL到所有订阅者

操作系统层面 #

完全可以实现单链路限速：

• 发布者侧可使用Linux下的tc命令，针对单个订阅者IP+Postgres服务端口（默认5432）的出站流量设置独立带宽阈值，不会影响其他业务流量
• 订阅者侧也可以用相同的tc规则，限制来自发布者IP的5432端口入站流量，适合没有发布者操作权限的场景

问题2：是否可对逻辑复制首次同步阶段的使用带宽进行限制？ #

可以实现，常用方案如下：

• 软限制：调整Postgres相关参数间接控制速率，比如调小basebackup_max_rate限制首次同步时基础备份的传输速率，或者调小max_sync_workers_per_subscription减少单个订阅者同时同步的表并发数，避免多表同步同时抢占带宽
• 硬限制：和常规逻辑复制链路的限流逻辑一致，用tc等OS级流量管控工具，对首次同步阶段的发布者-订阅者链路流量做临时或固定限速，首次同步完成后可调整回正常带宽阈值

适配你场景的优化建议 #

你的场景仅每月少数几次因大二进制文件写入触发带宽不足，还可以选择更根治的方案：

• 将大二进制文件存储到对象存储服务，Postgres仅存储文件的访问地址，从根源上避免大文件同步带来的带宽压力
• 若必须将文件存在Postgres中，可在写入大文件的时段临时调高限流阈值，非高峰时段恢复原有配置，平衡同步及时性和带宽占用

内容的提问来源于stack exchange，提问作者user1409708