Qlik Replicate同步RDS PostgreSQL至Synapse时Replication Slot突发GB级增长

问题场景 #

• 同步链路：Qlik Replicate 实现 RDS PostgreSQL 到 Azure Synapse 的数据同步，依赖PostgreSQL逻辑复制槽
• 异常表现：
  • 复制槽初始大小为MB级，随后以1GB/分钟的速度激增到GB级
  • 跳过每日产生8000万事务的高事务表后，同步延迟问题仍存在
  • 经Azure工程师确认，目标端Synapse无性能异常
  • 该高事务表配置为每5分钟执行一次Auto Vacuum

核心原因分析 #

1. WAL日志未及时被消费确认
   PostgreSQL逻辑复制槽会保留所有未被订阅端（Qlik Replicate）确认的WAL日志。如果Replicate的WAL消费速度跟不上RDS的WAL生成速度，槽内的日志会持续堆积膨胀。即使跳过高事务表的同步，该表频繁Auto Vacuum产生的大量WAL日志仍会被复制槽追踪（若发布范围未正确排除该表），进一步加剧堆积。

2. Auto Vacuum的过度触发
   每5分钟一次的Auto Vacuum在高事务表上会生成大量WAL（比如清理死元组、更新可见性映射等操作），即使不同步该表数据，这些WAL仍会进入复制槽，占用空间且拖慢消费效率。

3. Qlik Replicate内部处理瓶颈
   Synapse本身无异常不代表Replicate的处理无瓶颈：抽取线程的WAL解析速度、转换线程的数据处理能力、加载线程的Synapse写入并发度，任一环节不足都会导致WAL确认延迟，让复制槽持续保留旧日志。

4. PostgreSQL复制配置不合理
   max_logical_replication_workers、max_replication_slots等参数配置不足，会限制复制槽的处理效率；若发布范围设置为全库，即使Replicate侧过滤表，复制槽仍会追踪全库WAL，冗余日志直接导致槽膨胀。

可行解决措施 #

1. 精准控制逻辑复制的发布范围 #

不要在PostgreSQL侧配置全库发布，仅将需要同步的表加入发布对象，彻底排除高事务表。这样复制槽只会追踪指定表的WAL，从根源避免高事务表的冗余日志进入槽中。

2. 优化高事务表的Auto Vacuum策略 #

调整Auto Vacuum的触发条件，避免过度执行产生冗余WAL：

-- 针对高事务表调整Vacuum触发阈值，根据实际死元组情况设置
ALTER TABLE high_transaction_table 
SET (autovacuum_vacuum_threshold = 10000, autovacuum_vacuum_scale_factor = 0.05);

同时通过pg_stat_user_tables监控该表的死元组数量，确保Vacuum仅在必要时触发：

SELECT relname, n_dead_tup FROM pg_stat_user_tables WHERE relname = 'high_transaction_table';

3. 排查并优化Qlik Replicate性能 #

• 查看Replicate任务的运行日志，定位延迟环节（抽取/转换/加载阶段）
• 调整并行处理配置：增加抽取线程数、加载线程数，匹配Synapse的写入能力
• 确认Replicate是否及时向PostgreSQL发送WAL位置确认，避免复制槽无限保留旧日志

4. 监控复制槽状态 #

定期执行以下SQL查看复制槽的WAL滞后情况，判断是消费慢还是日志生成快：

SELECT 
  slot_name, 
  pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag_size,
  restart_lsn, 
  pg_current_wal_lsn() 
FROM pg_replication_slots 
WHERE slot_type = 'logical';

5. 调整RDS PostgreSQL的复制参数 #

• 确保max_logical_replication_workers（逻辑复制工作线程数）、max_replication_slots（最大复制槽数）配置足够支撑同步需求
• 避免过度设置wal_keep_size，该参数仅用于防止WAL被过早清理，无法解决复制槽的堆积问题

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