本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
使用原生数据库工具和 AWS DMS 进行迁移
DBAs 许多人熟悉处理数据库迁移和复制的各种工具。这些工具通常由数据库引擎供应商和第三方公司提供，它们在特定数据库引擎的逻辑层面上运行，这与应用程序迁移服务提供的完全不受应用程序限制的块级复制方法不同。
以下是这些工具的列表，从最简单到更复杂的方法：
-
完整备份/还原是 IT 人员熟悉、众所周知且易于使用的过程。该方法取决于数据库引擎的类型。该过程通常会移动位于同一数据库服务器上的多个逻辑数据库，也可用于将数据库恢复到托管服务，例如亚马逊关系数据库服务 (Amazon RDS)。 Backup/restore 是最简单的方法，但由于备份的大小以及在目标数据库上创建、复制和恢复备份所需的时间，因此与其他选项相比，需要更长的转换窗口。有关此方法的更多信息，请参阅 “规范性指南” 网站上的本机 SQL Server 备份/恢复和 Oracle RMAN。 AWS
-
逻辑备份或导出是另一种获取完整或部分逻辑数据库副本的方法。此本机数据库引擎工具允许您分解大型数据库服务器，以迁移与特定应用程序关联的选定数据库。它提供了比完全 backup/restore 控制迁移内容更多的控制权，还支持 Amazon RDS 作为目标。但是，出于与前一种方法相同的原因，此选项还需要更长的割接窗口。
-
原生数据库高可用性 (HA) 工具包括 Microsoft SQL Server 和 Oracle 的 Data Guard 复制中的始终开启或分布式可用性组群集。这种方法需要花费大量精力才能跨扩展的跨站点 HA 集群进行设置，并且可能会导致性能降低，因为实现完全同步的主动-主动部署需要更长的延迟。但这种方法在割接期间提供了接近于零的停机时间。
-
() 和原生数据库复制工具（例如 Oracle GoldenGate、Qlik 和 Talend AWS DMS）支持变更数据捕获AWS Database Migration Service (
CDC) 复制。您可以使用这些工具复制部分或完整的数据库，其优点是停机时间接近零，因为它们可以使目标数据库与源数据库保持同步。您也可以将此方法与 AWS Schema Conversion Tool (AWS SCT) 和 AWS DMS 异构迁移一起使用，同时对数据库进行迁移和现代化改造。 -
如果网络吞吐量是数据库迁移过程中的一个瓶颈，则可以将 AWS DMS 与 AWS Snowball
结合使用以进行大型数据库迁移与现代化。有关更多信息，请参阅博客文章 “使用 AWS DMS 和 AWS Snowball实现大规模数据库迁移 ”。
优点
与块级复制方法相比，使用数据库工具进行迁移具有以下优点：
-
有些工具可在最短的停机时间内完成迁移。其中包括 AWS DMS 支持原生 HA 集群或 CDC 复制的本机工具。
-
您可以使用大多数人熟悉的工具 DBAs 来迁移集群数据库。
-
作为迁移工作流程的一部分，您可以对数据库进行现代化改造，然后迁移到托管数据库服务，比如 Amazon RDS 或 Amazon Aurora。
-
在从单体基础架构迁移到微服务、拆分大型数据库服务器或集群，或者将较小的数据库合并到更大的实例或合并到更大的实例或中时，您可以利用整合和分解（或部分数据库迁移）。 AWS 服务
缺点
上一节中讨论的大多数好处都超出了典型的 lift-and-shift迁移场景，属于平台重组方法的范围。此外，本机数据库迁移方法在大规模迁移中也存在一些缺点，例如：
-
准备 - 在使用任何本机数据库方法之前，必须对目标基础设施、数据库服务器和集群进行完全预置和配置。
-
复杂性 - 某些方法（如完整备份或逻辑备份/还原）必须与另一种复制方法结合使用，以检测自创建初始备份以来的所有更改。
-
可扩展性 — 在大规模迁移时，没有简单的自动化框架可以将这些方法推广到其他数据库集群和服务器。
