一次 PostgreSQL 主备复制延迟问题，表面上看像是存储系统性能不足：主库不断产生 WAL，备用库却追不上。实际排查时，存储层、网络路径和 EC2 实例本身的带宽行为都可能参与其中。尤其当数据库使用挂载在 EC2 上的 Amazon FSx 文件系统时，单个 TCP 流的吞吐上限可能成为隐藏瓶颈。
延迟不一定来自 FSx 文件系统
典型架构是：PostgreSQL 主库和备用库运行在 EC2 上，数据目录或 WAL 相关目录使用通过网络挂载的 FSx 文件系统。主库写入 WAL，备用库通过复制连接接收并回放这些日志。
当备用库出现延迟时，常见直觉是检查 FSx 的吞吐配置、IOPS、延迟和突发能力。这些指标当然重要，但它们并不能覆盖完整路径：
PostgreSQL WAL sender
|
| 复制 TCP 连接
v
EC2 网络栈与单流限制
|
v
FSx 网络文件系统
|
v
PostgreSQL WAL receiver / replay
如果复制数据主要通过一条 TCP 连接传输，那么整条连接的有效吞吐可能受 EC2 单流带宽能力限制。此时，FSx 仍然可能有剩余吞吐，实例的总网络带宽也可能没有打满，但 PostgreSQL 复制已经无法继续提速。
这也是问题容易被误判的原因：监控面板显示“资源还有余量”，但复制延迟仍然持续增长。
用吞吐和产生速率判断瓶颈
复制延迟的核心判断可以简化为一个速率问题：
WAL 产生速率 > 复制连接有效传输速率
只要这个不等式持续成立，备用库落后的 WAL 量就会越来越大。即使业务高峰结束，备用库也可能需要较长时间才能追平。
可以在 PostgreSQL 中观察发送端、接收端和回放端状态。下面的查询适用于 PostgreSQL 主库，用于查看每个备用库的发送状态和 LSN 位置：
SELECT
application_name,
client_addr,
state,
sync_state,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)) AS unsent_wal,
pg_size_pretty(pg_wal_lsn_diff(sent_lsn, write_lsn)) AS network_gap,
pg_size_pretty(pg_wal_lsn_diff(write_lsn, flush_lsn)) AS receiver_flush_gap,
pg_size_pretty(pg_wal_lsn_diff(flush_lsn, replay_lsn)) AS replay_gap,
write_lag,
flush_lag,
replay_lag
FROM pg_stat_replication;
这些字段需要结合时间序列观察，而不是只看一次结果：
unsent_wal持续增长，说明发送端还没有把 WAL 送出去。network_gap较大，可能指向网络传输或接收端处理问题。replay_gap较大，说明 WAL 已经接收，但备用库回放速度不足。- 如果复制延迟与业务写入峰值同步出现，并且单条复制连接吞吐接近稳定上限，应把 EC2 单流带宽列入排查范围。
这些结论不是仅凭一个 PostgreSQL 指标就能确定。还要把数据库时间序列和 EC2、FSx、网络测试结果放在一起比较。
如何验证单流带宽限制
可以这样实践：在尽量接近生产网络路径的环境中，用 iperf3 比较单连接和多连接吞吐。测试前需要确认安全组和网络 ACL 允许测试端口，并避免在业务高峰直接压测生产链路。
在接收端启动服务：
iperf3 -s
在发送端先测试单个 TCP 流：
iperf3 -c <receiver-private-ip> -t 60 -P 1
再测试多个并行流：
iperf3 -c <receiver-private-ip> -t 60 -P 8
将 <receiver-private-ip> 替换为对端 EC2 的私有 IP。重点比较 -P 1 和 -P 8 的结果：
- 如果单流吞吐明显低于多流总吞吐，说明路径可能存在单流能力限制或单连接处理瓶颈。
- 如果单流和多流都很低，应继续检查实例类型、网络接口、路由、跨可用区路径和安全策略。
- 如果网络测试正常，但复制仍然落后，应转向 WAL 生成速率、备用库磁盘写入、WAL 回放、锁竞争和查询负载。
还可以在 EC2 上确认实例规格和网络接口状态：
aws ec2 describe-instances \
--instance-ids <instance-id> \
--query 'Reservations[].Instances[].{Type:InstanceType,AZ:Placement.AvailabilityZone,PrivateIp:PrivateIpAddress,ENIs:NetworkInterfaces[].NetworkInterfaceId}' \
--output table
aws ec2 describe-network-interfaces \
--network-interface-ids <eni-id> \
--query 'NetworkInterfaces[].{Status:Status,PrivateIp:PrivateIpAddress,Groups:Groups[].GroupId}' \
--output table
这些命令不会直接告诉你“复制连接的实际上限”，但能帮助确认实例类型、可用区和网络接口，避免把所有问题都归因于 FSx。
排查顺序与改进方向
遇到 FSx 上的 PostgreSQL 复制延迟，可以按下面的顺序收集证据：
- 记录主库 WAL 产生速率，以及备用库接收和回放速率。
- 区分延迟发生在发送、网络传输、接收还是回放阶段。
- 对照 FSx 的吞吐、IOPS 和文件系统延迟指标。
- 检查 EC2 实例类型、网络带宽说明和实际网络路径。
- 用单流、多流
iperf3测试验证是否存在明显差异。 - 在低风险时间窗口重复测试，并与复制延迟时间序列对齐。
如果确认单流带宽是瓶颈，可以评估以下方向：
- 选择具有更高网络性能的 EC2 实例类型。
- 调整数据库和 FSx 的拓扑，减少不必要的跨可用区或跨网络路径。
- 将对延迟敏感的 WAL 路径放到更适合该工作负载的存储架构中，前提是满足可靠性和恢复要求。
- 降低 WAL 产生峰值，例如检查批量写入、索引维护和高频更新任务。
- 确保备用库的 WAL 回放能力没有成为新的瓶颈。
不要只根据“FSx 监控没有打满”就排除网络问题，也不要仅凭一次 iperf3 测试就下结论。复制是一个端到端流程，最有价值的证据通常来自 WAL 速率、单连接吞吐、存储指标和时间线的交叉验证。
结语
AWS FSx 为数据库提供了方便的网络文件存储，但数据库复制性能取决于完整链路，而不是单一存储指标。当 PostgreSQL 备用库持续落后时，EC2 单流带宽限制应当成为检查清单中的一项，特别是复制流量集中在单条 TCP 连接、业务 WAL 产生速率较高的场景。
建议把单流与多流网络测试、pg_stat_replication 采样和 FSx 指标纳入常规容量评估。提前知道链路的有效边界，比等到备用库已经积累大量 WAL 后再追查原因更可靠。