AWS DMS源MongoDB目标RDS Postgres全量加载不生效仅持续复制正常

算力阿峰

2026-8-28

问题根因及对应解决方案

以下为该问题的常见触发场景及可直接落地的排查、修复操作：

1. 固定集合默认跳过全量配置触发

根因：MongoDB源端的异常集合为capped（固定集合）类型时，DMS MongoDB源端点默认开启Skip full load for capped collections参数，会直接跳过该类集合的全量加载流程，仅保留增量同步能力，全程不会输出错误日志，目标端仅会在捕获到第一条增量数据时创建对应空表。
排查方式：在源MongoDB执行db.<集合名>.isCapped()确认集合属性。
解决方案：
- 如果需要同步固定集合的全量数据，编辑源MongoDB端点，在端点特定配置中找到Skip full load for capped collections选项，设置为False后重新保存端点，重启DMS任务即可。
- 注意：固定集合为循环覆盖写入，全量加载无法保证数据一致性，建议在业务低峰期执行全量同步。

根因：配置表映射规则时，异常集合未被纳入全量加载的规则匹配范围（常见为include/exclude规则优先级配置错误、集合名大小写/特殊字符导致通配符匹配失效），但源端点开启了全库Change Stream捕获，CDC阶段拿到该集合的变更后会自动在目标端建表同步增量，全量阶段因未识别到该集合直接标记完成，无报错。
排查方式：打开任务的表映射配置，逐条核对规则优先级，使用DMS控制台的「测试表映射」功能，输入异常集合的完整库名、集合名，确认是否被标记为「需全量加载」。
解决方案：
- 修正表映射规则，确保异常集合被include规则命中，且优先级高于所有exclude规则；集合名存在特殊字符时优先使用精确匹配而非通配符匹配。
- 修正配置后选择「重载目标端表并重启全量同步」即可。

根因：如果之前曾对该集合创建过同步任务，DMS会在目标端Postgres的内部状态表（awsdms_status、awsdms_suspended_tables）中记录该集合已完成全量加载的位点信息；即便删除旧任务新建任务，只要复用了相同的源/目标端点，DMS启动时会读取该状态记录，直接跳过对应集合的全量流程进入增量。
排查方式：连接目标端RDS Postgres，查询内部状态表中是否存在异常集合的全量完成记录：
```
SELECT * FROM public.awsdms_status WHERE tablename LIKE '%<异常集合名>%';
```
解决方案：
- 停止当前DMS任务，手动删除目标端Postgres中对应异常集合的空表，同时删除内部状态表中该集合对应的所有记录。
- 重启任务时选择「从任务配置阶段重新启动」，触发全量扫描流程即可。

根因：3.4.7及更早的3.4.x版本、3.5.1及更早的3.5.x版本DMS引擎存在已知问题：当MongoDB源端读偏好配置为从Secondary节点读数据时，如果Secondary节点存在复制延迟，DMS全量阶段执行count校验拿到的文档数为0，会直接标记集合全量完成，不会实际拉取文档，CDC阶段不受影响。
排查方式：查看DMS复制实例的引擎版本，同时在全量任务启动阶段，登录源MongoDB Secondary节点执行db.<集合名>.count()确认返回值是否为0。
解决方案：
- 将DMS复制实例引擎升级到3.4.8/3.5.2及以上稳定版本。
- 临时规避方案：将源端点的读偏好临时调整为Primary节点，待全量加载完成后再切回Secondary节点即可。

根因：如果异常集合数据量过大、或者源端MongoDB实例负载过高，全量阶段元数据扫描请求超时，DMS会默认将该集合判定为“无数据需要全量加载”，仅在trace级别的日志中记录超时信息，常规debug级别日志不会输出报错，后续CDC阶段正常建表同步增量。
排查方式：将DMS日志级别调整为trace，搜索关键词skip full load due to metadata scan timeout确认是否存在对应集合的超时记录。
解决方案：
- 编辑DMS任务的全量加载配置，将SourceMaxFullLoadReadTime参数从默认的300秒调整为1800秒，同时调大MaxFullLoadSubTasks的并行数，降低单批次拉取的文档块大小。
- 业务低峰期重启任务执行全量加载即可。

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