升级Aurora PostgreSQL引擎后AWS DMS任务无法恢复求助

• 源端：Aurora PostgreSQL 14.9（刚完成大版本升级，原版本已达EOL）
• 目标端：Kafka
• AWS DMS配置：V3.5.2版本复制实例，任务类型为全量加载+持续复制
• 前置状态：升级前DMS任务运行正常；升级时因大版本要求删除了原有复制槽，升级后重建了同名复制槽
• 当前问题：恢复DMS任务失败，无法从原有偏移量继续CDC捕获，抛出异常日志

错误日志 #

Slot has plugin 'null' (postgres_test_decoding.c:233)

Last commit event from source was less than end of full load time, with no cached events present. Switching sorter to apply mode (sorter_transaction.c:3105)

Slot has plugin 'test_decoding' (postgres_test_decoding.c:233)

Sampled CDC backend configuration is: wal_level=logical , max_wal_senders=20 , max_replication_slots=20, wal_sender_timeout=60000 (postgres_endpoint_util.c:1347)

Can't resume task after replication slot was dropped. [1020101] (postgres_endpoint_capture.c:418)

1. 修正复制槽的插件类型 #

DMS依赖的复制槽必须使用pglogical插件（而非日志中出现的test_decoding），手动创建或修正步骤：

• 检查现有复制槽的插件：

SELECT slot_name, plugin FROM pg_replication_slots;

• 如果目标槽的plugin不是pglogical，先删除无效槽：

SELECT pg_drop_replication_slot('your_slot_name');

• 重新创建符合要求的复制槽：

SELECT pg_create_logical_replication_slot('your_slot_name', 'pglogical');

2. 重置DMS任务的CDC起始点 #

原复制槽删除后，旧任务的偏移记录已失效，无法通过“恢复任务”功能直接复用，需手动指定起始位置：

• 停止当前失败的DMS任务
• 编辑任务，在CDC开始位置选项中选择自定义，输入升级前最后一次成功捕获的LSN（可从升级前的DMS任务日志、PostgreSQL历史复制槽记录中获取）
• 保存配置后重新启动任务

3. 验证基础配置有效性 #

• 确认Aurora PostgreSQL的rds.logical_replication参数仍为1，且wal_level=logical、max_replication_slots等参数满足DMS需求
• 检查DMS复制实例的IAM权限，确保拥有访问Aurora PostgreSQL复制槽、读取WAL日志的权限

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