AWS DMS将MongoDB作为源端，是否会自动排除系统集合

问题描述：

MongoDB作为AWS DMS的source endpoint，启动了system.profile，但是DMS迁移完成后，目标端没有这个集合。有时候我们会比较好奇原因。

AWS官方文档上没有明确的DMS是否会排除此类集合的详细说明，那么DMS内部是如何对其处理的？

分析过程 及 解决方案：

1. 理论支持是，MongoDB将系统信息存储在使用.system.* 命名空间的集合中，该命名空间由MongoDB保留供内部使用。启用profile以后，system.profile会作为一个系统集合进行储存。

这些系统集合类似于MySQL当中的mysql，information_schema, performance_schema. 而Profile本身类似于audit log.

2. DMS服务确实通过内部组件，默认skip掉所有的system开头的集合。

当我们打开METADATA_MANAGER的detailed_debug级别的日志以后，我们能够看到DMS进行了如下内部操作：

01669079: 2023-10-25T10:23:48:371752 [METADATA_MANAGE ]I: Skipping System Collection "admin"."system.roles" from the source. (mongodb_metadata.c:151) 
01669079: 2023-10-25T10:23:48:371773 [METADATA_MANAGE ]I: Skipping System Collection "admin"."system.users" from the source. (mongodb_metadata.c:151) 
01669079: 2023-10-25T10:23:48:371781 [METADATA_MANAGE ]I: Skipping System Collection "admin"."system.version" from the source. (mongodb_metadata.c:151) 
01669079: 2023-10-25T10:23:48:371788 [METADATA_MANAGE ]I: Skipping System Collection "admin"."system.profile" from the source. (mongodb_metadata.c:151) 
01669079: 2023-10-25T10:23:48:371795 [METADATA_MANAGE ]I: Skipping System Collection "admin"."system.keys" from the source. (mongodb_metadata.c:151)

AWS DMS 服务的内部代码是写死的，自动skip掉所有的system集合，包括system.profile。

结论：

system.roles，users，version这些，都属于元数据内容，本就不必迁移到新库里。 system.profile类似于“audit log”或者“general log”，也没有迁移的必要。

对于其他引擎，如果我们遇到类似问题，也可以将metadata_manager组件的detailed debug日志打开并进行测试，这是解决DMS问题的一个常规且有效的途径。