将数据从一种数据库迁移到另一种数据库通常都非常具有挑战性，特别是考虑到数据一致性、应用停机时间、以及源和目标数据库在设计上的差异性等因素。这个过程中，运维人员通常都希望借助于专门的数据迁移（复制）工具来降低操作的复杂性和对业务的影响。AWS数据迁移服务（AWS DMS）可帮助AWS用户快速、安全、无缝地将MongoDB、Oracle、MySQL和Microsoft SQL Server等数据库迁移到AWS。 源数据库在迁移期间仍然可以运行，因此最大程度地减少了依赖于数据库的应用程序的停机时间。
MongoDB是一个流行的跨平台的面向文档的NoSQL数据库，拥有非常多的应用场景和很大的用户群体。但是某些情况下用户需要将MongoDB迁移或者复制到关系数据库，比如将文档数据从MongoDB复制到MySQL来进行复杂关连分析处理，或者由于在数据库选型方面分析不够，错选了数据库类型而需要迁移到关系数据库。
在本文中，我们将讨论将MongoDB 4.0数据平滑迁移到Amazon Aurora MySQL兼容版的方法。Amazon Aurora 是一种与 MySQL 和 PostgreSQL 兼容的关系数据库，专为云而打造，既具有传统企业数据库的性能和可用性，又具有开源数据库的简单性和成本效益。本文中描述的方法使用AWS DMS转换源数据，近乎零停机时间来执行迁移。
设置MongoDB 4.0源数据库
安装并配置MongoDB 4.0，然后将standalone的MongoDB转换成replica set（rs），因为我们要进行的是full load + CDC的复制，DMS需要访问MongoDB的操作日志（oplog），为了创建oplog，需要部署一个rs。
1.配置yum，创建/etc/yum.repos.d/mongodb-org-4.0.repo，以便直接使用yum安装MongoDB：
2.安装MongoDB包
3.配置bindIP，MongoDB server默认只允许loopback连接，为了允许从VPC或者internet连接，做以下设置：
a.编辑/etc/mongod.conf文件，找到以下行：
b.修改bindIP为ec2实例的public IP或者private IP：
c.保存/etc/mongod.conf文件，重启mongod：
4.将standalone的MongoDB转成replica set：
a.关闭mongod服务
b.重启mongod：
用hostname和ip地址替换以上参数
c.用mongo shell连接mongod：
d.用initate()初始化新的replica set
5.向MongoDB里导入数据：
a.使用wget命令下载包含样例数据的Json文件
b.使用mongoimport命令导入数据到一个新的数据库（zipsdb）
c.检查导入的数据:
到此为止，我们成功安装了MongoDB 4.0社区版，设置了replica set为CDC做准备，并且导入了测试数据到zipsdb数据库，数据库中有一个名为zips的collection。
在AWS账号下启动一个Aurora集群，作为目标数据库
通过AWS控制台launch一个Aurora MySQL集群，具体参考创建数据库集群
利用DMS进行MongoDB在线迁移
将 MongoDB 用作源时，AWS DMS 支持两种迁移模式。用 AWS 管理控制台通过 Metadata mode (元数据模式) 参数指定迁移模式，或在创建 MongoDB 终端节点时指定额外的连接属性 nestingLevel。所选的迁移模式将影响目标数据的结果格式，如下所述。
文档模式：
在文档模式下，MongoDB 文档按“原样”迁移，这意味着文档数据将并入目标表中一个名为 _doc 的列中。文档模式是您将 MongoDB 用作源终端节点时的默认设置。
表模式：
在表模式中，AWS DMS 将 MongoDB 文档中的每个顶级字段转换为目标表中的一个列。如果有嵌套字段，则 AWS DMS 会将嵌套值平展到单个列中。随后，AWS DMS 将关键字段和数据类型添加到目标表的列集。
本文中使用表模式进行迁移，架构示意如下：
创建复制实例
AWS DMS 使用复制实例连接到源数据存储，读取源数据并设置数据格式以供目标数据存储使用。复制实例还会将数据加载到目标数据存储中。
AWS DMS 始终在基于 Amazon Virtual Private Cloud (Amazon VPC) 的 VPC 中创建复制实例。您可以指定复制实例所在的 VPC。可以使用您账户和 AWS 区域的默认 VPC，也可以创建新的 VPC。源和目标终端节点连接到 VPC 或者位于 VPC 内部，以此来访问位于 VPC 内部的复制实例。本文中源、目标数据库和复制实例在一个VPC内部，因此可以使用private IP连接。实例配置如下，可以根据task的大小选择合适的实例类型，对于重要的任务也可以使用Multi AZ部署方式。
以下屏幕截图是创建复制实例的示例：
创建源MongoDB endpoint
以下屏幕截图创建一个源endpoint指向前面创建的replica set中的zipsdb，Metadata mode设置为table。
创建目标Aurora endpoint
以下屏幕截图创建了一个target类型的endpoint，指向Aurora集群的writer节点。
创建迁移任务
创建DMS迁移任务，指定源端点为前面创建的源MongoDB端点“mongo-rs”，任务类型为“migrating existing data and replicate ongoning changes”，打开cloudwatch日志便于诊断任务执行情况。
在Table mappings部分，选通过selection rules设置需要复制的schema和table，在transformation rules里设置如何改变／转换schema，table或者column。在下面任务设置截图里，通过selection rules，选择将源MongoDB里的zipsdb.zips表箱目标Aurora库里复制。
跟踪任务运行情况
Full load
任务启动之后很快进入“Load complete，replication ongoing”状态，表示完成了full load，进入持续复制阶段。
以上屏幕截图显示当前已经完成了29353行数据的full load。让我们在源、目标端验证一下。
源端记录总数：
目标端复制后的database和table，以及记录总数：
经过full load之后，目标端Aurora中已经复制了MongoDB的database和collection到相应的database和table，一条document对应zips表里的一行。
CDC
在源MongoDB我们进行以下CRUD操作，然后在目标端Aurora MySQL确认同步情况。
1.新增一条记录到zips表：
在Aurora检查该文档复制情况：
2.在MongoDB更新该文档：
在目标端Aurora MySQL确认同步情况：
3.在源端delete该文档：
在目标端MySQL表中确认记录删除：
DMS任务复制统计数据
可以发现，源端所做的DML（2 Insert，2 Deletes，2 Updates）已经被实时捕获并复制到目标端。
总结
本文我们讨论了使用AWS DMS进行连续数据捕获（CDC）近乎实时的复制最新版本的MongoDB 4.0的文档数据到Aurora MySQL兼容版的表中。截至目前AWS DMS官方文档中虽然声明只支持MongoDB 2.6.x和3.x，但是本文的演示证明AWS DMS对MongoDB 4.0也是完美支持的。如果有复杂的关连分析需求，使用DMS将MongoDB的文档实时复制到Aurora MySQL将使您可以借助关系数据库弥补MongoDB在这个方面的不足，亦或者您需要在MongoDB向关系数据库迁移的过程中保持业务系统在线，尽可能降低停机时间，DMS的CDC功能可让您的迁移过程举重若轻。