PostgreSQL的pg_repslot文件堆积+Debezium复制异常排查求助

核心现象 #

• 随机触发集群复制停止，Debezium日志无有效报错，但CPU负载骤增
• pg_repslot目录文件持续堆积，不删除复制槽会耗尽磁盘空间
• 无法终止复制槽关联PID，仅重启Kafka Connect/PostgreSQL无法恢复；必须停止Kafka Connect、重启PostgreSQL并删除复制槽才能恢复，否则Debezium持续卡在日志：

  Searching for WAL resume position (io.debezium.connector.postgresql.PostgresStreamingChangeEventSource:323)
  

排查方向 #

1. PostgreSQL WAL 清理与复制槽的冲突 #

• 检查wal_keep_size/archive_timeout配置：若Debezium追LSN速度远慢于WAL生成/归档速度，会导致复制槽请求的WAL已被清理，触发Debezium全量扫描找LSN，引发CPU飙升和复制停滞
• 查询pg_stat_replication和pg_replication_slots，对比复制槽的restart_lsn与pg_current_wal_lsn()的差距：差距过大说明Debezium长期追不上，复制槽阻止WAL清理导致pg_repslot堆积
• 核查遗留应用的写入行为：老旧应用可能存在批量写入、大事务，短时间生成大量WAL，超出Debezium处理能力

2. Debezium 2.0.1版本兼容性BUG #

• 该版本存在与PostgreSQL 11/13兼容的已知问题：
  • 大事务或DDL后，复制槽LSN追踪异常，导致Debezium无限循环查找WAL位置
  • 多数据库共享单复制槽时，LSN同步逻辑冲突
• 尝试升级至Debezium 2.1.x及以上稳定版本验证问题是否解决

3. 复制槽进程僵死与资源泄漏 #

• 执行以下查询确认复制槽状态：

  SELECT slot_name, active, pid, restart_lsn FROM pg_replication_slots;
  SELECT pid, usename, application_name, client_addr FROM pg_stat_replication;
  

  若pid存在但对应进程已僵死（通过ps aux核对），说明PostgreSQL未正确清理复制槽关联进程，导致WAL无法推进
• 检查max_replication_slots配置：若复制槽数量接近上限，会引发资源竞争导致异常

4. 老旧应用的隐性Schema变更或异常写入 #

• 核查PostgreSQL日志（pg_log），确认复制停止前后是否有DDL操作、大事务提交或异常写入记录——老旧应用可能存在动态表生成、隐性字段修改等行为，导致Debezium解析异常卡住复制

5. Kafka Connect资源瓶颈 #

• 检查Kafka Connect的JVM堆内存配置：堆内存不足会导致Debezium处理大WAL批次时GC频繁或OOM，引发复制停滞，进而导致PostgreSQL端WAL堆积
• 查看Kafka Connect任务状态：是否存在任务重启、分区不平衡，导致Debezium无法持续消费WAL数据

临时应急操作 #

• 若允许，暂停遗留应用的批量写入，降低WAL生成速度
• 清理已归档的过期WAL文件，临时释放磁盘空间
• 替换复制槽：创建新复制槽并切换Debezium使用，待原复制槽restart_lsn超过当前WAL位置后再删除原槽

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