Data Migration Service 可靠运维指南

1. 概述

背景与目标

在中国区的数据库迁移与数据集成实践中，我们经常会遇到异构数据库迁移、双向同步、对高可用 / 最小业务影响迁移和数据库升级等场景。DMS（Database Migration Service）是亚马逊云科技提供的一个托管型迁移 / 数据同步服务，DMS可以提供强大的跨数据库同步数据的能力。作为数据产品，我们常常说“数据无小事”，怎样高效且安全的运维DMS成为很多运维人员面临的问题。本文从以下三个方面带您了解如何安全可靠的运维DMS：

组件篇 – 介绍配置起一个DMS同步任务的基本组件，以及这些配置在运维层面的影响

运维篇 – 针对不用的任务配置，不同的业务场景分享安全操作策略以及注意事项

监控篇 – 介绍关键指标，确保DMS 稳定运行

2. 组件篇

DMS是面向同构/异构数据库迁移与持续同步（CDC）的托管服务，常用于快速把存量数据做全量迁移，再以增量变更保持源与目标的低延迟一致。要把 DMS “跑稳、跑快、对生产影响小”，第一步就是吃透它的核心组件与配置边界 – 多数运维问题，往往在组件层的选择与参数上的设置已埋下伏笔。

将两个数据库利用DMS同步数据仅需要三个组件的配合：

2.1复制实例(Replication Instance)

定位：一台运行着DMS服务的托管硬件。其角色定位是承担数据全量复制、CDC (changed data capture) 捕获与重放、数据缓存/缓冲与写入目标数据库。复制实例的 CPU / 内存 / 存储 IO / 网络IO 直接决定数据同步的吞吐与延迟。

关键配置项与运维影响

配置维度	常见取值	运维影响	建议
实例规格	DMS只提供T, C, R 系列实例。	DMS 主要的收费单元。尽量选择合适的实例类型和大小，过小的实例可能引起内存不足造成同步任务的自动停止。	1. T系列不建议在生产场景下使用 2. 在 C、R 系列中，第 6 代与第 5 代同价但性能更高，建议优先选择 6 代实例 3. R 系列适合大表大事务场景。C 系列适合高频DML场景，DMS 中配置转换规则场景。 4. 机型建议从小规格起步，关注内存占用，再逐步扩到更大规格
存储	默认50GB	主要用于日志存储以及数据同步时缓存用。该配置无法通过修改进行缩容	磁盘无法通过修改缩容，磁盘不足会导致同步数据异常，建议采取从小到大原则，根据监控调整磁盘大小
版本	新建复制实例会默认设置DMS版本	新版本包含安全修复、可靠性补丁与兼容性改进。	关注“当前默认引擎版本”“停止创建日期”“强制升级日期（EOL）”，将其纳入运维台账与变更日历。支持生命周期可见附录DMS release note 地址。
VPC	默认VPC	DMS 复制实例所处的网络边界，决定它能否安全、稳定地访问源库/目标库	路由表，NACL，安全组需要放行DMS 流量否则会造成DMS 无法连接源和目标库

注意：

DMS复制实例是“共享资源池”：

实例硬件资源瓶颈会影响到所有配置在同一复制实例上的同步任务。
任何一个同步任务占用过多的资源都会影响同一个复制实例上的其他同步任务。

2.2 复制端点(Replication Endpoint)

定位：如果把复制实例比作一座承载数据同步的桥，那么复制端点就是指明这座桥连接的两端 – 指定哪两个数据库进行数据同步。

配置维度

说明

运维影响

建议

连接基本项

指定数据库host/port/user/password等

可能因为网络联通问题导致DMS无法连接数据库。

或用户的权限不足无法开启同步

网络联通性确认和测试。权限确认等

DMS 源数据库捕获日志变更条件

Binlog，redo log 等

对源数据库开启日志，避免同步失败

可以和DBA 协同，根据源数据库的类型进行日志配置。

2.3 复制任务(Replication Tasks)

定位：有了承载同步的复制实例，并通过复制端点确定了源库与目标库。下一步就需要用复制任务告诉 DMS：同步什么、如何同步、何时同步。复制任务的可配置性很强，但也因此在后续运维中，因配置与操作差异，容易对业务产生不同程度的影响。

迁移类型 (migration type)	说明	任务状态及常见使用场景
迁移 (full load)	从源数据库到目标数据库执行一次性全量数据迁移。	全量数据迁移完成后任务会自动停止。适用于一次性同步或数据初始化场景。
迁移和复制 (full load and CDC)	先执行一次性全量迁移，然后持续复制源数据库的增量变化数据，实现持续同步。	全量迁移完成后任务会持续运行，实时复制增量数据。适用于两个数据库保持持续同步的场景。
复制 (CDC Only)	不做全量迁移，仅持续复制源数据库的增量变化数据。	任务持续运行，仅同步增量数据。适用于目标端已具备全量数据，只需后续变更同步的场景。

当任务启动或重启（restart）时，DMS 会根据所选的目标表准备模式自动执行相应的数据准备操作。

目标表准备模式(Target table preparation mode)	说明	任务状态及常见使用场景
不执行任何操作 (Do nothing)	不对目标表做任何改动，DMS 直接将数据写入目标表。若目标表中已存在数据，新的全量迁移会与原数据叠加。	适用于目标端已存在结构和部分数据，且不希望清空或重建的场景。常用于增量/部分重跑，但需特别注意重复数据风险。
删除目标中的表 (Drop tables on target)	在任务开始前，DMS 会先删除目标端对应的表（包含数据和结构），再重新建表并迁移数据。	适用于全量重新迁移或表结构/数据需彻底重置的场景。可确保表结构与源端保持一致，但会导致原有数据全部丢失。尽量避免配置该准备模式
截断 (Truncate)	在任务开始前，DMS 会对目标端表执行截断操作（Truncate），清空表中数据但保留表结构，然后重新加载全量数据	适用于结构无需重建但数据需重置的场景。相比 Drop，更快且对表结构影响小，适合单表 Reload 或定期重载

需特别注意，尽管单个复制任务可以同步多个数据库或表，但其配置项是全局生效的，即同一任务下仅能使用一套配置策略。

以上两个复制任务的配置直接和我们运维操作挂钩，我们日常运维DMS时需要时刻关注复制任务以上两个配置的详细。根据不同的维护场景和复制任务的配置进行调整以上两个复制任务的配置与日常运维操作密切相关。在 DMS 的日常维护中，需要持续关注并理解这两项配置的具体含义，并根据不同的运维场景灵活调整，才能最大程度减少对业务的影响。

3. 运维篇

在完成稳健的任务配置后，运维的重点转向如何在变更与维护中保持系统稳定。本章将基于典型场景，阐述相应运维策略，并深入解析重启语义与分级机制，以实现对生产环境的最小扰动。

3.1制定DMS 运维流程

DMS 运维不仅仅是技术操作，更是一项需要流程规范与业务协同的系统性工作。制定标准化的运维流程，不仅有助于降低人为操作和配置冲突的风险，还能够避免目标数据库因同步异常而不可用，防止错误数据进一步影响上层业务服务，从而有效保障整体系统的稳定性与业务连续性

3.1.1变更评审: DMS管理员把控变更评审，根据任务配置评审运维操作以及评定操作的影响范围。

3.1.2测试预演: 测试环境灰度任务验证

3.1.3低峰执行: 尽量在业务低峰期进行DMS运维操作。并预留充足的维护窗口，为出现异常时的全表加载留出缓冲时间。

3.1.4制定预案: DMS 数据同步多需要重新加载表解决，DMS 管理员需告知业务部门可能影响，如果目标数据库服务于其他应用系统需要统一系统停机时间与维护窗口，形成明确的操作预案与沟通机制。

3.1.5双端校验: 如果是重新复制场景需要验证数据同步生效，另外如果是DDL修改，目标端必须确认DDL 生效。

3.2 标准化运维操作

在明确了 DMS 运维流程的制定原则之后，接下来要做的，就是将这些流程标准化、场景化，形成可重复执行、可追溯的操作规范。
DMS 的运维既包含日常的变更与维护，也涵盖问题发生后的快速排查与恢复。只有做到“能跑得稳，也能动得稳”，才能最大程度降低 DMS 对生产系统的潜在影响。

从实践来看，DMS 运维重点主要体现在两个方面：

日常运维规范：聚焦 DDL 变更与运维操作时机，确保变更过程安全、同步行为可控

问题排查与恢复操作：针对任务异常、同步中断等问题，给出标准化的排查思路和操作策略。

3.2.1 日常运维规范

DDL 运维规范：

DMS 支持一部分通用的 DDL 操作（可参考官方文档 Supported DDL），但不同目标端的支持能力并不一致。
例如：当目标端为 Amazon Redshift 时，加列操作并不被支持。
因此，任何 DDL 操作完成后，都必须在目标端验证变更是否同步生效，必要时再通过单表变更流程进行修复。

严格把控 DDL 操作权限

所有 DDL 建议由 DBA 统一执行，避免开发或应用侧直接修改源数据库结构，导致 DMS 任务异常。

所有 DDL 建议都在源库执行

目标数据库中的表结构变更尽量依赖 DMS 自动同步，避免在目标端手动执行DDL。

新增表建议在源库创建

源库新建表后，若任务未启用“% 同步所有表”，需手动更新 DMS 任务同步规则。

由 DMS 创建目标端表结构并同步数据后，再按需创建外键和索引。

DDL 执行后必须验证目标端

如果目标端未同步变更，应执行单表重启或 reload 流程，确保结构一致性。

复制任务的维护规范：

源端和目标端数据库维护时停止 DMS 任务

包括小版本升级、主从故障转移（Amazon RDS / Amazon Aurora）、参数修改重启类操作。

DMS 复制实例维护时停止任务

包括实例配置调整、DMS 版本升级等操作，避免在维护过程中造成数据不一致或任务中断。

维护操作完成后进行任务的恢复操作(resume)

3.2.2问题排查与恢复操作

在实际运维中，DMS 任务可能因网络波动、源库异常、DDL 不匹配或配置冲突等原因出现同步中断或失败。
此时需要有一套清晰的排查与恢复流程，确保能快速恢复同步，并将业务影响降到最低。

DMS 任务恢复操作建议:

确认业务影响范围

同业务部门说明DMS 任务失败或停止的影响：

1. 任务停止不影响目标数据库的存量数据
2. 停止期间源数据库增量数据无法同步
3. 触发DMS 复制任务重启可能清空或覆盖目标端数据，在全量数据同步完前目标表数据不可用。需谨慎评估。

选择合适的重启级别

任务级别重启：

此操作基于任务级别进行操作，多针对于任务失败或停止。如果触发重启，任务中配置的所有表都将按表的准备模型进行数据操作，影响较大。

1. 先尝试恢复(resume), 恢复任务不会影响目标数据库数据。只会触发任务重新启动。
2. 重启(restart) 前需要根据表的准备模式和业务部门确认和说明影响。得到同意后进行
3. 当表的准备模式是删除目标表时(Drop tables on targets)，需保留建表语句和二级索引。因为二级索引不能被DMS 同步，在DMS 建表和同步数据完成后，需要手动创建二级索引。另外应避免配置删除目标表为表的准备模式
4. 当表的准备模式是不执行任何操作时 (Do Nothing)，需要手动删除/截断目标表，避免目标数据库表数据重复
5. 当表的准备模式是截断时(truncate), 目标表数据会被清除在完成全量数据加载前，目标表数据将不可用。

单表级别重启(推荐)

此操作基于单表操作，影响较小，多用于单表数据不一致，表结构不一致等场景。任何重新加载操作前和业务部门确认和说明影响。

1. 源端数据表和目标数据表结构不一致：备份二级索引和建表语句，删除目标表后触发单表的重载(reload)
2. 源端数据表和目标数据表数据不一致时：截断目标表，触发单表重载(reload)

4. 监控篇

在实现了稳健的配置与标准化的运维操作之后，接下来要关注的是如何通过有效的监控和告警机制，做到“早发现、快响应、可联动”。本章将围绕 DMS 复制实例与任务的关键监控指标、告警阈值设定以及自动化联动策略，帮助实现对同步链路的持续可视化与可控化。

从实践来看，DMS 监控重点可以放在以下两个方面:

复制实例：资源层监控，关注底层计算、存储与网络资源的健康状态，例如内存占用、CPU 利用率、磁盘 I/O、网络吞吐以及剩余存储空间等。这类指标直接影响 DMS 任务的稳定性和持续运行能力，是判断性能瓶颈与资源不足的第一道信号。

复制任务：服务层监控，聚焦数据链路与业务同步的健康情况，例如 CDC 延迟、吞吐量、错误率与进度状态等。这类指标反映的是同步链路的实时状态与业务层表现，可用于提前发现异常、定位同步卡点，并支撑故障分流与告警联动。

4.1复制实例 – 资源层

FreeableMemory: 可用内存；该指标过低易引起 OOM (out of memory)。表现为任务随机停止

SwapUsag: 交换区使用量；持续上升意味着内存吃紧

CPUUtlization: CPU 使用率；持续高位为计算瓶颈信号

Network In/Out：网络瓶颈/异常监测

FreeStorageSpace：空间不足会导致缓存/日志写失败

4.2复制任务 – 服务层

复制任务的监控可以根据任务的类型选择监控维度。主要指标为：

CDCLatencySource：源库到复制实例的 CDC 延迟；源端事务未提交/链路异常常导致该值升高。

CDCLatencyTarget：复制实例到目标库的延迟；与事务大小、目标写入能力相关。

Throughput（FullLoad/CDC/Apply）：全量与增量吞吐基线与趋势。

Error/FailedChanges：错误与失败行监测。

PercentageDataLoaded / StopReason：全量进度与停止原因，用于进度把控与异常分流。

5. 结语

DMS（Database Migration Service）是连接源库与目标库的数据通道，更是支撑关键业务平稳运行的数据同步基座。它的高效运维不仅依赖工具本身的能力，更取决于我们对整个生命周期的理解、规划与执行。

在组件篇中，我们介绍了复制实例、复制端点与复制任务三大核心组件的配要点，这些参数和选择往往决定了任务能否“跑得稳”。
在运维篇中，我们通过标准化的流程和规范，将“可能出错的环节”前移到可控的预案中，同时规范各个实际场景中需要对DMS 采取的操作。让变更和维护“动得稳”。
在监控篇中，我们通过对资源层与服务层的关键指标监控，为持续稳定运行提供了第三道防线。

DMS 运维并不是一次性的“上线动作”，而是一项需要持续管理、协同与优化的系统性工程。
一套合理的配置策略、标准化的运维流程以及完善的监控告警体系，可以大幅降低生产风险，避免数据同步中断，保障业务连续性与数据的高可用。

参考链接：

DMS release Note: https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReleaseNotes.html

DMS supported DDL: https://docs.aws.amazon.com/zh_cn/dms/latest/userguide/CHAP_Introduction.SupportedDDL.html

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

亚马逊AWS官方博客