DMS 宝典 - 轻松迈出数据库上云第一步

近期 AWS 在 BJS 和 ZHY region 推出了 AWS Database Migration Service 服务（以下简称 DMS），它可以帮助我们在很多场景完成数据库迁移：

• 可以将数据迁入或迁出 Amazon EC2 上建立的数据库或 Amazon RDS

• 支持同构或异构数据库的迁移

• 支持 7*24 小时 online 的数据库迁移

• 可以进行跨 region、跨账号的数据库数据迁移

• 当 ZHY 推出 aurora 数据库后，很多客户希望从现有数据库迁移到 aurora，而 DMS 的推出，恰逢其时，为客户提供了一个数据库迁移的利器。那么接下来，我将通过一个使用 DMS 迁移 BJS region 中 Oracle 数据库的数据到 ZHY region 中 aurora 数据库的案例，让大家更好地了解 DMS 服务。

基本原理

对于数据库迁移来说，大致可以分为两个阶段：

1 在目标数据库上生成 schema，如果是同构数据库迁移，这一步骤相对简单，如果是异构数据库迁移，则会复杂很多，因为异构数据库迁移涉及数据库引擎变化，不同数据库的数据对象定义有所不同，甚至可能出现部分源数据库的数据对象在目标数据库中不支持的现象。我们的 AWS Schema Conversion Tool（以下简称 SCT）可以帮助我们自动对 schema 进行转换，对于复杂的异构数据库迁移，我们可以通过 SCT 产生基础脚本，DBA 再进行人工加工，最终在目标数据库生成 schema。

2 将数据迁移到目标数据库， DMS 可以支持全量加载和变更捕获复制，也就说既可以只将历史数据迁移，也可以在两个数据库之间完成持续增量数据同步。在此过程中， DMS 会自动管理支持您的迁移服务器的基础设施的所有部分，包括硬件和软件、软件修补和错误报告。

下图阐明了 AWS DMS 的主要组件：

• Replication instance 是 DMS 使用复制软件自动配置的服务器。DMS 提供了自动故障转移。如果您的主复制服务器因任何原因发生故障，则备份复制服务器可接管运行，这可以保证 replication task 不会因为 Replication instance 的宕机而失败

• 为源和目标数据库创建 endpoint，并保证 Replication instance 可以连接两个 endpoint

• 创建 replication task，将选定的数据从源数据库复制到目标数据库

迁移流程

使用 DMS 完成对一个 7*24 小时 online 数据库最小停机时间迁移的大致流程如下：

前期准备

1.生成目标数据库

2.在源和目标数据库上生成专门用于迁移的数据库用户并授权

3.对于 CDC 任务，需要参考文档，在源数据库上做相应设置，譬如开启归档，补充日志等

4.生成复制实例，设置 网络环境, 保证复制实例可以连接到源数据库和目标数据库

5.生成两个数据库的 endpoint , 测试复制实例可以连接

6.如果字符集有不兼容问题，考虑在迁移前对源数据库数据进行处理

7.SCT 会帮助我们转换 schema, 但 DBA 手工干预依然重要

生成启动 DMS 任务

1.创建 full load and CDC DMS 任务

2.如果数据量巨大, 考虑拆分成多个任务并行处理

3.必要时考虑在目标数据库 删除 PK/UK/index 来加速 full load 任务

4.Full Load 任务期间在目标数据库需要禁用外键检查并 disable 所有 trigger 以避免数据同步异常

5.Full load 任务结束后生成约束和 index 以加速 CDC 任务，但确保 triggers 继续处于 disabled 状态

6.通过 CDC 任务 完成持续变更捕获复制，在源和目标数据库之间同步数据，等待切换窗口

切换过程

1.目标数据库端验证所有数据库对象均已生成

2.应用端测试验证功能流程可以在目标数据库上顺利完成

3.考虑回退选项，是否需要保留从目标数据库切换回源数据库的可能

4.验证源、目标两个数据库中关键数据一致

5.在业务低谷期，将源数据库置为只读，等待 CDC 任务 的 replicate lag 变为 0

6.在目标数据库处理 Sequences 并 enable triggers

7.切换数据库，将应用指向目标数据库

8.数据库切换后的检验，监控

迁移案例

所谓“纸上得来终觉浅，绝知此事要躬行”，我们用一个案例来演示如果使用 DMS 跨 region 迁移异构数据库，让大家对 DMS 有一个直观的认识。本案例中源数据库是我在 BJS region 中 EC2 上创建的 Oracle 数据库，目标数据库则是 ZHY region 中的 aurora RDS 数据库。

1 环境准备

1.1 源数据库

在源数据库上创建专用于 DMS 任务的用户 dmsadmin 并授权。当然您可以用现有用户执行 DMS 任务，但是使用专用用户可以让您轻松地将 DMS 任务产生的数据变更和正常业务产生的数据变更区分开来，而且也更容易对用户进行管理。

如果您要使用 CDC 任务不要忘了按照文档对源数据库做额外设置，譬如开启补充日志。登陆源数据库执行：

create user dmsadmin identified by dmsadmin;
grant DBA to dmsadmin;
alter database force logging;
alter database add supplemental log data;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
select name,log_mode,supplemental_log_data_min,supplemental_log_data_pk,supplemental_log_data_pk,force_logging from v$database;

最后的查询输出应类似：

1.2 目标数据库

在目标数据库上生成专用于 AWS DMS 任务的用户 dmsadmin 并授权。登陆目标数据库并执行：

create user dmsadmin identified by ‘dmsadmin’;
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT,SHOW VIEW,REFERENCES,CREATE VIEW,TRIGGER,CREATE ROUTINE,ALTER ROUTINE,EXECUTE ON *.* TO dmsadmin;
flush privileges ;
show grants for dmsadmin;

2 转换 Schema

接下来我们将是用 SCT 来转换 schema，请遵循官方文档，根据自己的平台下载安装最新的 SCT https://docs.aws.amazon.com/zh_cn/SchemaConversionTool/latest/userguide/CHAP_Installing.html

而后打开 SCT，创建一个新的 project，命名为 oracle to aurora，并选择源数据库引擎为 oracle，目标数据库引擎为 aurora mysql

连接源 oracle 数据库，输入服务器地址，端口、SID 等连接信息，用新建立的 DMS 任务专用用户名，密码登录，测试连接通过后点击 OK

同样地连接目标 aurora 数据库，输入服务器地址，端口、SID 等连接信息，用新建立的 DMS 任务专用用户名，密码登录，测试连接通过后点击 OK

连接后可以看到源和目标数据库的 schema 信息，点击上方菜单中的 settings 选择 mapping rules 添加映射规则，我们模拟一个需求，要将源数据库上的 PULSE schema 转换为 test schema ，先点击 add new rule，在弹出的界面中选择类型 schema，输入 PULSE，然后 action 选择 rename 目标填入 test，最后点击 save，添加一条映射规则。

添加规则后，在左侧源数据库 schema 列表里选择要导出的 schema，右键引出菜单，然后单击 covert schema

转换 schema 后，在右侧目标数据库 schema 列表里会出现新的 test schema，我们点击 test 右键引出菜单，有两个选择，一种是直接 apply to database，完全依赖 SCT 完成 schema 转换，在目标数据库上直接生成 schema；另一种是选择 save as SQL 将 SCT 转换的结果保存为 SQL 脚本，而后在此基础上进行人工干预，生成最终 SQL 脚本并运行该脚本在目标数据库上创建 schema。对于异构大型数据库迁移，如果涉及一些源数据库的对象在目标数据库上不支持，那么 DBA 的人工干预就是必不可少的，建议大家在目标数据库上生成 schema 之前，务必人工 review 脚本。

3 生成复制实例和 endpoint

3.1 生成子网组

接下来我们将生成 DMS 相关资源，首先按文档为 IAM 用户赋予相应权限https://docs.aws.amazon.com/zh_cn/dms/latest/userguide/CHAP_Security.IAMPermissions.html ，使用 IAM 用户登陆 AWS console 并进入 DMS 主页，在左侧列表中选择 subnet groups 创建子网组，在您的 VPC 内选择子网，请确保选择的子网至少覆盖两个可用区。

3.2 生成复制实例

接下来在左侧列表选择 replication instances 创建复制实例，请注意如下设置：

1 实例类型，复制实例对抽取数据的处理发生在内存中。但是，大型事务可能需要部分缓冲到磁盘上。缓存事务和日志文件也会写入磁盘。目前可选的实例类型有 T2、C4 和 R4 Amazon EC2 实例类型，T2 实例类型用于测试环境，DMS 在执行异构迁移和复制时可能会占用大量 CPU，C4 实例类型很适合，如果源数据库有很大吞吐量，则会消耗更多内存，此时 R4 实例类型优化的内存会很有帮助。如果选择的复制实例资源不足会导致 DMS 任务缓慢，甚至极端的时候可能导致任务失败。

2 多可用区部署，选择多可用区选项时，复制实例使用多可用区部署提供高可用性和故障转移支持。在多可用区部署中， DMS 自动在不同可用区中预置和维护复制实例的同步备用副本。复制实例崩溃不会导致 DMS 任务失败

3 网络设置，不仅仅是复制实例所在的网络设置，包括源数据库和目标数据库所在的网络也需要进行妥善设置，确保复制实例可以连接源和目标数据库

4 维护设置，AWS DMS 会在您指定的运维窗口期定期对 AWS DMS 资源譬如复制实例或复制实例的操作系统 (OS)进行更新。维护会暂停 DMS 任务，维护后继续任务。

3.3 生成源和目标数据库的 endpoint

在左侧列表中选择 endpoint，生成源和目标数据库的 endpoint，首先选择 endpoint type 是 source 还是 target，而后分别输入 endpoint 的名称，数据库引擎，数据库服务器地址，端口等连接信息以及是否用 SSL 连接，用新建的 dmsadmin 用户登录。

最后用我们创建的复制实例测试连接，连接通过后创建 endpoint，如果您面对连接测试失败，请检查连接信息是否正确，另外请查看您的网络设置。

4 生成并运行 DMS 任务

现在万事俱备只欠东风，我们来创建 DMS 任务迁移数据，在启动 full load DMS 任务前，请务必确保目标数据库的外键约束检查被关闭以及 trigger 被 disable，因为在 full load 任务加载数据时，不能保证父表数据会先于子表加载，如果此时开启外键约束可能会报错，同样地在数据迁移阶段启动 trigger 也可能导致数据异常。

在左侧列表中选择 tasks，然后点击 create task。此前我们已经创建了复制实例，源和目标 endpoint，现在我们需要给 task 命名，并作出设置：

1 任务类型 DMS 支持三种任务类型，在这里我们选择 Migrate existing data and replicate ongoing changes

Migrate existing data: 在 API 中称为 full-load，选择该选项， DMS 将仅迁移现有数据。不捕获对源数据的变更，也不会将这些变更应用于目标。如果您的停机窗口足够长或者要搭建测试环境时可以选择此项

Migrate existing data and replicate ongoing changes: 在 API 中称为 full-load-and-cdc，选择该选项， DMS 可在迁移您的现有数据时捕获变更。在初始加载数据后，AWS DMS 会继续捕获和应用变更。最终，源数据库和目标数据库将保持同步，从而实现停机时间最少的迁移。

Replicate data changes only: 在 API 中称为 cdc ，仅捕获并复制变更

2 是否创建任务后立刻启动，如果选择，任务创建成功后会立刻启动

3 CDC stop mode：指定 CDC 任务是否停止以及停止的时间，停止的时间可以指定源上的提交时间或复制实例上的服务器时间，这里我们不指定停止时间

4 target table preparation mode：3 种对目标表的准备模式，我们这里选择 Do nothing

Do nothing – 不更改目标表的数据和元数据。如果前期已经在目标数据库上生成了 schema，而且没有冲突数据，选择此项

Drop tables on target – drop 表并在其位置创建新表。但注意 AWS DMS 不会创建二级索引、非主键约束或列数据默认值。

truncate – truncate 表，但保留表的结构。譬如初始加载曾经失败，再次加载时可以选择此项

5 stop task after full load complete：这里选择 Don’t stop，初始加载后立刻开始 CDC 任务，但是如果是大型系统，有时候我们会为了加速初始加载删除二级索引甚至主键和唯一约束，那么初始加载后可以暂停任务，重新生成主键/唯一约束和二级索引，这些可以用来加速后续的 CDC 任务，因为约束和索引有助于定位后续变更的行。

• Don’t stop– 不停止任务，初始加载后立刻开始 CDC 任务

• Stop before applying cached changes–初始化加载开始后的变更会缓存，初始加载完成后应用这些缓存的变更再停止任务

• Stop after applying cached changes– 初始加载完成后不应用缓存的变更就停止任务

6 Include LOB columns in replication，Limited LOB mode 速度更快，但会将 LOB 截断为最大 LOB 大小参数的值，从而造成数据丢失

• Don’t include LOB columns -从迁移操作中排除 LOB 列

• Full LOB mode – 迁移整个 LOB，而不管大小如何。AWS DMS 以块的形式分段迁移 LOB，块的大小受最大 LOB 大小参数的控制。此模式比受限 LOB 模式的速度要慢

• Limited LOB mode – 将 LOB 截断为最大 LOB 大小参数的值。此模式比使用完整 LOB 模式的速度要快

• 7 Enable validation 启用数据验证，确定是否准确地将数据从源迁移到目标。

8 Enable logging 启用日志记录，可以从 Amazon CloudWatch 监控任务，请务必开启日志记录，这对我们监视，调优，troubleshooting DMS 任务有巨大的帮助。

9 在 table mappings 部分可以设置加载数据范围和映射信息，点击添加 selection rule，选择要加载的数据，指定 schema，action 选择 include

10 添加 transformation rule，譬如我们选择要加载的 schema 通过 action 下拉菜单选择 rename to，可以将源数据库的 schema 转换到新的 schema；再比如 ORACLE 数据字典内存储的表名列名等信息都是大写，那么可以在这里指定转为小写，选择 target 为 table 或 column。完成以上设定后最后点击创建任务。

5 DMS 任务的监控

因为我们选择了 start task on create，故而任务创建后自动开始运行，执行 full load，可以通过 console 看到任务的 status 先是 starting，而后是 running，full load 结束后变为 load completed，从下面详细信息部分，选择 table statistics 页签，可以看到我们有 3 张表要加载，三张表的 full load rows 和 total 部分值一样，说明历史数据已经全部加载完毕，我们可以通过 select count(*)语句对源数据库和目标数据库对应表的行数进行进一步检测。

另外，因为我们选择了 logging enabled，通过选择 logs 页签，可以看到 cloudwatch 的链接，点击可以看到 DMS 运行日志，今后我们如果要监控，调优乃至 troubleshooting DMS 任务，这里是首先要查看的部分。

在 full load 加载完毕后，根据我们前面的选择，DMS 自动进入 CDC 阶段，我们在源数据库端对 EMP 表执行了一系列的增删改查，可以看到 table statistics 部分中，对 EMP 表上发生后续变更的数量有所记录，我们同样可以进一步通过 SQL 语句在源和目标数据库分别进行验证，数据也完全一致，这样就可以证明 CDC 任务运行正常。

至此，我们的跨 region，异构数据库迁移已经完成了大部分，接下来我们需要和应用团队商定一个切换窗口期，遵照前面我们提到的切换流程，将应用程序切换到目标数据库，整个数据库迁移工作就大功告成了。

总结

本文介绍了 DMS 任务的基本原理，数据库迁移的大致流程，并用一个跨 region 异构数据库迁移的案例让大家对 DMS 有了一个直观的认识，相信大家也发现了 DMS 是一款安全、便捷而高效的迁移数据库利器，希望大家充分利用 DMS，轻松迈出数据库上云的第一步。

当然，数据库迁移是一个庞大而复杂的工程，尤其将数据库迁移上公有云，除了数据库知识更需要了解公有云上网络，存储，虚拟化等一系列知识。但是，我们不应该仅仅将数据库上云看做一个复杂的任务，更应该把它当做一个优化我们数据库的契机，关于如何选择合适的云端数据库，如何迁移非关系型数据库上云等话题，限于篇幅本篇 blog 这里没有涉及，敬请期待我们后续的 blog。

相关文章：

《AWS Schema Conversion Tool 用户指南》 https://docs.aws.amazon.com/zh_cn/SchemaConversionTool/latest/userguide/CHAP_Installing.html

《AWS Database Migration Service 用户指南》https://docs.aws.amazon.com/zh_cn/dms/latest/userguide/Welcome.html

作者介绍：

吕琳

AWS 解决方案架构师，负责基于 AWS 的云计算方案的咨询与架构设计，同时致力于数据库和大数据方面的研究和推广。在加入 AWS 之前曾在 Oracle 担任高级讲师并在 Amazon 担任高级 DBA，在数据库设计运维调优、DR 解决方案、大数据以及企业应用等方面有丰富的经验。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/dms-cloud-first-step/