基于Debezium的AWS RDS Postgres CDC逻辑复制问题咨询

一、复合主键表逻辑复制配置问题 #

1. 不创建publication是否可运行逻辑复制 #

结论是完全不可行，你前期的调研结论准确。
PostgreSQL原生逻辑复制体系（包括Debezium默认使用的pgoutput解码插件）以publication作为变更捕获的最小单元：所有需要同步的表、需要捕获的操作类型（insert/update/delete）都必须通过publication声明，逻辑解码过程只会输出publication覆盖范围内的变更事件。即使你在Debezium侧配置了表级过滤规则，底层仍然依赖数据库端创建的publication获取初始变更流，不创建publication的情况下复制槽启动时会直接抛出配置错误，不存在绕过方案。

2. REPLICA IDENTITY FULL的优化方案 #

首先需要澄清一个常见误区：复合主键本身并不强制要求设置REPLICA IDENTITY FULL，出现该报错的核心原因是你的表没有满足REPLICA IDENTITY DEFAULT模式的生效条件：即表存在所有列均非空的正式主键约束。很多场景下开发人员会把带可空列的复合唯一索引当成主键使用，或者没有显式创建主键约束，才会触发需要设置FULL的提示。
你可以按优先级选择以下方案替代全局设置FULL，大幅降低性能损耗：

• 优先修正主键配置：对使用复合主键的表，确认主键是通过PRIMARY KEY (col1, col2, ...)语法正式创建的，且所有主键列均设置了NOT NULL约束。满足该条件的复合主键可以完美适配默认的REPLICA IDENTITY DEFAULT模式，WAL中只会记录复合主键包含的列值作为旧行标识，无额外性能开销，不需要修改副本标识配置。
• 无法修正主键约束时使用索引副本标识：如果因为业务限制无法给复合主键列加非空约束、或者无法创建正式主键，可以选择表上一个所有列均非空、能唯一标识每一行数据的唯一索引，执行ALTER TABLE <你的表名> REPLICA IDENTITY USING INDEX <你的索引名>;。该模式下WAL只会记录索引包含的列值，相比FULL模式记录整行所有旧列值的方案，WAL写入量、逻辑解码的CPU开销可降低60%~80%，是性价比最高的替代方案。
• 仅当表上不存在任何可用的非空唯一索引时，才退而求其次使用REPLICA IDENTITY FULL，这类表建议严格控制高频率的批量update/delete操作，避免大事务导致WAL体积暴涨。

二、复制槽导致数据库存储无限增长问题 #

根因 #

这是PostgreSQL逻辑复制的机制决定的，不属于bug：为了保证变更不丢失，PostgreSQL会永久保留所有复制槽尚未确认消费的WAL日志，不会触发自动清理。只要复制槽的消费位点停止推进，后续生成的所有WAL都会持续堆积，最终占满磁盘空间，删除复制槽后数据库会自动清理该槽位关联的所有未消费WAL，存储占用就会恢复正常。
常见的位点停滞原因包括：Debezium连接器异常退出且长时间未恢复、下游消费速度远跟不上WAL生成速度、实例长时间无业务变更时没有心跳机制推进位点。

解决方案 #

• 配置复制槽延迟监控：重点监控RDS实例的Oldest Replication Slot Lag指标，设置延迟超过1GB或延迟时间超过10分钟的告警规则，出现异常时第一时间排查Debezium连接器状态，避免连接器长时间宕机导致WAL持续堆积。
• 开启Debezium心跳机制：配置heartbeat.interval.ms参数（建议设置为300000，即5分钟），即使没有业务数据变更，Debezium也会定期向复制槽发送位点更新请求，避免长周期无变更时位点停滞导致WAL无法清理。
• 配置异常复制槽自动清理规则：新版本AWS RDS PostgreSQL支持rds.logical_replication_slot_timeout参数，可设置复制槽超过指定时间无消费连接时自动失效，释放对应的WAL空间。如果你的实例版本不支持该参数，可以配置定时巡检脚本，定期检查所有复制槽的延迟值，当延迟超过预设阈值时自动删除异常停滞的复制槽，后续重启Debezium连接器时会自动触发初始快照恢复同步，不会造成数据不一致。
• 优化Debezium消费性能：根据业务流量调整max.batch.size、max.queue.size等消费参数，提升下游数据处理速度，保证复制槽位点推进速度匹配WAL生成速度，从根源避免堆积问题。

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