Debezium重启后restart_lsn未移动，WAL堆积、复制槽滞后增长

针对Spring Boot中Debezium消费消息后restart_lsn不移动、复制槽滞后增加且重启重复消费的问题，结合你的测试环境配置（snapshot.mode=never），给出以下排查与解决步骤：

1. 验证偏移量提交逻辑与存储配置 #

Debezium依赖偏移量记录跟踪已消费的WAL位置，若偏移量未正确提交或存储，会导致重复消费且restart_lsn不更新：

• 若使用Debezium Embedded模式，必须配置持久化的偏移量存储（而非默认内存存储），比如文件存储：

  FileOffsetBackingStore offsetStore = new FileOffsetBackingStore();
  offsetStore.setFile(new File("./debezium-offsets.dat"));
  
  EmbeddedEngine engine = EmbeddedEngine.create()
      .using(connectorConfig)
      .using(offsetStore)
      .notifying(record -> {
          // 消息处理逻辑
          // 避免此处抛出未捕获异常，导致偏移量提交中断
      })
      .build();
  

• 检查offset.flush.interval.ms配置（默认60000ms），若业务处理耗时较长，可适当调整该值，确保偏移量能及时提交。

2. 检查PostgreSQL逻辑复制配置与权限 #

复制槽active状态为f，说明Debezium未维持住与PostgreSQL的复制连接：

• 确认postgresql.conf中逻辑复制相关配置正确：

  wal_level = logical
  max_replication_slots = 10  # 需大于当前使用的复制槽数量
  max_wal_senders = 10
  

• 检查pg_hba.conf，允许Debezium使用的数据库用户从应用IP进行复制连接：

  host    replication     debezium_user    192.168.0.0/24    scram-sha-256
  

• 验证数据库用户拥有REPLICATION权限：

  ALTER USER debezium_user WITH REPLICATION;
  

3. 排查Debezium连接活跃性问题 #

复制槽非活跃通常是连接器线程异常或资源耗尽导致：

• 查看应用日志，搜索PostgresConnector、WalPosition等关键字，排查是否有连接超时、WAL读取失败、线程阻塞等异常信息。
• 若使用Kafka Connect部署Debezium，检查连接器任务状态，确认是否存在频繁重启或失败的情况。

4. 测试环境下重置复制槽（谨慎操作） #

由于是本地测试环境，可通过重置复制槽解决历史LSN异常问题：

-- 删除现有复制槽
SELECT pg_drop_replication_slot('debezium');

删除后重启Spring Boot应用，Debezium会重新创建复制槽并从最新WAL位置开始消费。注意：此操作会丢失未处理的WAL日志，仅适合测试场景。

5. 临时调整snapshot.mode配置 #

当前snapshot.mode=never会跳过初始快照，若连接器启动时无法正确定位到最新LSN，可能导致重复读取旧变更：

• 临时将snapshot.mode改为initial，启动应用执行一次全量快照，完成后再改回never，验证是否解决重复消费问题。

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