AWS RDS逻辑复制槽持续滞后问题求助及并行流复制咨询

问题背景 #

我们在AWS RDS上搭建了PostgreSQL逻辑复制，针对多数数据库表创建了发布和订阅。初始全量表复制完成后，变更数据捕获（CDC）启动运行。

错误日志 #

一段时间后，订阅端出现以下日志：

2024-09-24 05:08:26 UTC::@:[22213]:ERROR: could not receive data from WAL stream: SSL SYSCALL error: EOF detected
2024-09-24 05:08:26 UTC::@:[705]:LOG: background worker "logical replication worker" (PID 22213) exited with exit code 1
2024-09-24 05:08:26 UTC::@:[22296]:LOG: logical replication apply worker for subscription "......" has started

问题现象与已尝试操作 #

• 日志出现后，对应复制槽的WAL滞后量持续增长，目前已达150GB
• 尝试过启用/禁用订阅、刷新发布，问题未解决
• 增大wal_sender_timeout和wal_receiver_timeout后，SSL错误日志消失，但滞后量仍持续上升
• 偶尔复制槽会变为活跃状态，restart_lsn也会向前推进，但整体滞后量依旧增加

核心疑问 #

1. 是否应该将订阅的streaming模式改为并行模式？该设置有哪些注意事项？
2. 还有哪些其他解决方案可以解决当前的滞后问题？

发布端配置 #

┌───────────────────────┬─────────┐
│         name          │ setting │
├───────────────────────┼─────────┤
│ max_replication_slots │ 20      │
│ max_wal_senders       │ 35      │
│ wal_level             │ logical │
│ wal_sender_timeout    │ 300000  │
└───────────────────────┴─────────┘

订阅端配置 #

┌─────────────────────────────────┬─────────┐
│              name               │ setting │
├─────────────────────────────────┼─────────┤
│ max_logical_replication_workers │ 8       │
│ max_replication_slots           │ 20      │
│ max_worker_processes            │ 20      │
│ wal_receiver_timeout            │ 300000  │
└─────────────────────────────────┴─────────┘

解决方案分析 #

关于并行流复制的可行性与注意事项 #

可以尝试启用订阅的并行流复制，但需注意以下几点：

1. 版本要求：PostgreSQL 10及以上版本支持该特性，需确保AWS RDS的PostgreSQL实例满足版本要求
2. 参数适配：
   • 订阅端需保证max_logical_replication_workers和max_worker_processes有足够余量（当前订阅端max_logical_replication_workers=8，可根据负载调整，但不能超过max_worker_processes的限制）
   • 修改订阅模式的命令示例：

     ALTER SUBSCRIPTION your_subscription_name SET (streaming = parallel);
     

3. 冲突风险：并行复制会用多个worker并行应用WAL变更，若订阅端存在大量跨表事务、或事务内有依赖关系的变更，可能引发冲突或数据不一致，需确认业务场景中此类情况占比极低
4. 资源消耗：并行worker会占用更多CPU、内存资源，需实时监控订阅端实例的资源使用率，避免出现资源耗尽

其他解决方案 #

1. 精准定位瓶颈
   • 查询订阅端pg_stat_subscription视图，分析apply_lag、receive_lag的具体数值，区分是WAL接收阶段还是变更应用阶段滞后
   • 查看发布端pg_stat_replication视图，检查WAL发送速率、是否存在阻塞
2. 提升订阅端性能
   • 确保订阅端实例的CPU、内存、IO资源充足，AWS RDS可临时升级实例规格来加速追平滞后
   • 暂停订阅端不必要的后台任务（如自动分析、非紧急备份），优先保障复制worker的资源分配
3. 排查网络链路
   • 虽SSL错误已消失，但仍需确认发布端与订阅端之间的网络延迟、带宽是否达标，AWS内可检查VPC peering、路由是否存在瓶颈，跨可用区/区域场景需重点关注网络带宽
4. 重置复制（谨慎操作）
   • 若滞后量过大且短时间无法追平，可考虑重新初始化订阅：先删除现有订阅，重新创建并执行全量复制。此操作会导致订阅端数据短暂不可用，需在业务低峰期进行
5. 优化发布配置
   • 检查发布是否包含不必要的表或大事务，拆分大事务为小事务，减少单批次处理的数据量
   • 确认发布端wal_sender_timeout设置合理，避免因超时频繁断开连接（当前设置5分钟，可根据网络稳定性微调）

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