本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 第 3 阶段：迁移
在您完成迁移计划并确定迁移策略后，实际迁移便开始了。在此阶段，将设计目标数据库，将源数据迁移到目标数据库，并对数据进行校验。
![\[Iterative migration process\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-database-migration/images/iterative-migration-process.png)
这是一个迭代过程，包括多个转换、迁移和测试周期。功能和性能测试完成后，您可以割接到新数据库。
迁移阶段包括以下关键步骤（以下部分将讨论）：
+ [转换架构](convert-schema.md)
+ [迁移数据](migrate-data.md)
+ [更新应用程序](update-app.md)
+ [测试迁移](test-migration.md)
+ [切换到新数据库](cut-over.md)
# 转换架构
数据库迁移期间的关键作业之一是将架构从源数据库引擎迁移到目标数据库引擎。如果您重新托管或更换平台，您的数据库引擎不会改变。这称为*同构数据库迁移*，您可以使用本机数据库工具来迁移架构。
但是，如果您要重新架构应用程序，则架构转换可能需要更多工作。在这种情况下，您将进行*异构数据库迁移*，其中源数据库引擎和目标数据库引擎将有所不同。您当前的数据库架构可能正在使用无法直接转换为目标数据库引擎的软件包和功能。有些功能可能以不同的名称提供。因此，转换架构需要对源数据库引擎和目标数据库引擎有很好的了解。这是一项具有挑战性的作业，具体取决于您当前架构的复杂性。
AWS 提供了两种资源来帮助您进行架构转换：AWS Schema Conversion Tool(AWS SCT) 和迁移手册。
## AWS SCT
AWS SCT 是一款免费工具，可以帮助您将现有数据库从一个引擎转换为另一个引擎。 AWS SCT 支持许多源数据库，包括Oracle、Microsoft SQL Server、MySQL、Sybase 和 IBM Db2 LUW。您可以从 Aurora MySQL 和 Aurora PostgreSQL 等目标数据库中进行选择。
AWS SCT 提供了直接连接到源数据库和目标数据库以获取当前架构对象的图形用户界面。连接后，您可以生成数据库迁移评估报告，以获得转换工作和操作项目的高级摘要。以下屏幕插图显示了数据库迁移评估报告示例。
![\[Sample database migration assessment report from AWS SCT\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-database-migration/images/sct-assessment-report.png)
使用 AWS SCT 可以转换架构并将其直接部署到目标数据库中，也可以获取转换后的架构的 SQL 文件。有关更多信息，请参阅 AWS 文档中的[使用 AWS Schema Conversion Tool 用户界面](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_UserInterface.html)。
## 迁移行动手册
尽管 AWS SCT 转换了许多源对象，但转换的某些方面需要手动干预和调整。为帮助完成这项作业， AWS 提供了迁移行动手册，其中详细介绍了两个数据库之间的不兼容性和相似之处。有关这些行动手册的更多信息，请参阅 AWS 网站上的 [AWS Database Migration Service 资源](https://aws.amazon.com/dms/resources/)。
# 迁移数据
架构迁移完成后，您可以将数据从源数据库移动到目标数据库。根据应用程序可用性要求，您可以运行一个简单的提取作业，将源数据一次性复制到新数据库中。或者，您可以使用一种工具来复制当前数据并继续复制所有更改，直到准备好切换到新数据库为止。对于重新托管和更换平台，我们建议您使用本地数据库专用工具来迁移数据。
可以帮助您进行数据传输的工具包括 AWS Database Migration Service(AWS DMS) 和离线迁移工具。以下各节介绍了这些信息。
## AWS DMS
在使用 AWS SCT 将架构对象从源数据库引擎转换为目标引擎之后，您可以使用 AWS DMS 迁移数据。借助 AWS DMS，您可以在复制数据的同时保持源数据库的正常运行。您可以对数据执行一次性拷贝，也可以使用连续复制进行复制。当源数据库和目标数据库同步时，您可以使数据库脱机并将操作移至目标数据库。AWS DMS 可用于同构数据库迁移（例如，从本地 Oracle 数据库迁移到 Amazon RDS for Oracle 数据库）以及异构迁移（例如，从本地 Oracle 数据库迁移到 Amazon RDS for PostgreSQL 数据库）。有关使用 AWS DMS 的更多信息，请参阅 [AWS DMS 文档](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html)。
## 离线迁移选项
除 AWS DMS 外，您还可以使用其他选项从源数据库提取数据并将其加载到目标数据库。当数据迁移活动期间允许应用程序停机时，这些选项最为合适。例如以下方法：
+ 从加载到目标数据库的源数据库中提取的逗号分隔值 (CSV)
+ 对于 Oracle 源数据库，可使用 **ora2pg** 实用程序将数据复制到 PostgreSQL
+ 自定义提取、转换、加载 (ETL) 作业，将数据从源复制到目标
# 更新应用程序
数据库迁移从来都不是仅于限数据库的迁移。您必须查看使用数据库的应用程序，以确保它在新数据库中按预期运行。如果您只是重新托管或重新构建同一个数据库引擎，则更改微乎其微，但如果您决定迁移到新的数据库引擎，则更改可能会更繁多。
如果您的应用程序依赖对象关系映射 (ORM) 与数据库进行交互，则在迁移到新的数据库引擎时并不需要很多更改。但是，如果您的应用程序具有自定义的数据库交互或动态构建的 SQL 查询，则更改可能会很大。查询格式可能会存在差异，需要加以纠正，以确保应用程序按预期运行。
例如，在 Oracle 中，将字符串与 `NULL` 连接将返回原始字符串。但是，在 PostgreSQL 中，将字符串与 `NULL` 连接将返回 `NULL`。另一个例子是如何处理 `NULL` 和空字符串。在 PostgreSQL 中，`NULL` 和空字符串是两回事，而像 Oracle 这样的数据库则以相同的方式处理它们。在 Oracle 中，如果插入列值设置为 `NULL` 或空字符串的行，则可以使用 `where` 子句提取这两种类型的值：`where is NULL`。在 PostgreSQL 中，此 `where` 子句将只返回列值实际为 NULL 的一行；它不会返回字符串值为空的行。有关这些区别的更多信息，请参阅 [AWS Database Migration Service 资源](https://aws.amazon.com/dms/resources/) 页面上列出的迁移行动手册。
# 测试迁移
功能和性能测试是数据库迁移的重要组成部分。详细的功能测试将确保您的应用程序在使用新数据库时不会出现任何问题。您应该投入时间来开发单元测试，以测试应用程序工作流程。
性能测试可确保您的数据库响应时间在可接受的时间范围内。您可以识别瓶颈，进行优化并重复性能测试。您可以根据需要重复该循环以获得所需的性能结果。
测试可以是手动的，也可以是自动的。建议您使用自动化框架进行测试。在迁移过程中，您将需要多次运行测试，因此拥有自动测试框架有助于加快错误修复和优化周期。
此测试可以发现开发阶段遗漏的问题。例如，任何转换错误的查询都将失败或返回不正确的结果，从而导致功能测试失败。性能测试可以发现诸如索引缺失导致查询响应时间变慢之类的问题。它们还可以发现需要根据工作负载调整数据库引擎或修改查询的性能问题。
# 割接
数据库割接策略通常与应用程序的停机时间要求密切相关。可用于数据库割接的策略包括离线迁移、快闪迁移、主动/主动数据库配置和增量迁移。以下各节将讨论这些内容。
## 离线迁移
如果可以在写入操作期间让应用程序长时间脱机，则可以使用 AWS DMS 满载作业设置或离线迁移选项之一进行数据迁移。迁移进行期间，读取流量可以继续，但必须停止写入流量。由于需要从源数据库复制所有数据，因此会占用源数据库资源，例如 I/O 和 CPU。
总体来说，离线迁移涉及以下步骤：
1. 完成架构转换。
1. 开始停机写入流量。
1. 使用离线迁移选项之一迁移数据。
1. 验证您的数据。
1. 将应用程序指向新数据库。
1. 结束应用程序停机时间。
## 快闪迁移
在快闪迁移中，主要目标是将停机时间降至最低。此策略依赖于从源数据库到目标数据库的连续数据复制 (CDC)。迁移数据时，当前数据库上的所有读/写流量都将继续。由于需要从源数据库复制所有数据，因此会占用源服务器资源，例如 I/O 和 CPU。您应该进行测试以确保此数据迁移活动不会影响您的应用程序性能 SLA。
总体来说，快闪迁移涉及以下步骤：
1. 完成架构转换。
1. 在连续数据复制模式下设置 AWS DMS。
1. 当源数据库和目标数据库同步时，请验证数据。
1. 启动应用程序停机时间。
1. 推出该应用程序的新版本，该版本指向新数据库。
1. 结束应用程序停机时间。
## 主动/主动数据库配置
主动/主动数据库配置包括设置一种机制，在源数据库和目标数据库都用于写入流量时保持源数据库和目标数据库同步。与离线或快闪迁移相比，此策略涉及更多工作量，但在迁移期间亦提供了更大的灵活性。例如，除了在迁移期间最大限度地减少停机时间外，您还可以按受控的小批量将生产流量转移到新数据库，而不必执行一次性割接。您可以执行双写操作以便对两个数据库进行更改，也可以使用类似 [HVR](https://www.hvr-software.com/product/) 的双向复制工具来保持数据库同步。这种策略在设置和维护方面更加复杂，因此需要进行更多测试以避免数据一致性问题。
总体来说，主动/主动数据库配置涉及以下步骤：
1. 完成架构转换。
1. 将现有数据从源数据库复制到目标数据库，然后使用双向复制工具或从应用程序进行双向写入，使两个数据库保持同步。
1. 当源数据库和目标数据库同步时，请验证数据。
1. 开始将一部分流量转移到新数据库。
1. 继续转移流量，直到所有数据库流量都转移到新数据库。
## 增量迁移
在增量迁移中，您可以将应用程序分成较小的部分迁移，而不是执行一次性的完全割接。根据您当前的应用程序架构或您意愿在应用程序中进行的重构，这种割接策略可以有多种变化。
您可以使用[设计模式](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/)添加新的独立微服务，以替换现有整体遗留应用程序的某些部分。这些独立的微服务有自己的表，应用程序的任何其他部分都不能共享或访问这些表。您可以使用任何其他直接割接策略将这些微服务逐一迁移到新数据库。迁移后的微服务开始使用新数据库进行读/写流量，而应用程序的所有其他部分则继续使用旧数据库。迁移完所有微服务后，即可停用遗留应用程序。这种策略将迁移分成更小、更易于管理的部分，因此可以减少一次性大规模迁移带来的风险。
# 对 AWS 遵循以下最佳实践
除了前几节中讨论的迁移活动外，您还应投入时间确保遵循最佳实践以将数据库托管在 AWS 云中。有关使用 AWS 关系数据库的最佳实践，请参阅 [AWS 文档](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html)。