发布于: Aug 8, 2022
只要可能，我们都会提前创建服务与基础设施。例如，在开始迁移之前，我们的 Aurora MySQL 数据库、SQL 服务回滚数据库以及 DMS 实例都已经准备就绪。
即 SQL Server 服务的初始状态。
在这一步中，我们将正式开始从 SQL Server 到 Aurora MySQL 的全加载迁移。所谓全加载迁移，实际上是一套时间点快照副本，DMS 负责将数据从源数据库复制到目标数据库。
从数据库的约束角度来看，要想获得最佳全加载性能，理想的作法是在导入全加载前仅部署各主键。在全加载之后，我们再逐步添加其他约束元素，例如外键。由于DMS 会从多个表处并行加载数据，因此复杂的外键关系可能会减慢加载过程。在 Aurora MySQL 上，最好只包含写入节点。而在 SQL Server 回滚设置中，理想的作法是在主节点中创建回滚数据库。另外，在单一节点上创建索引会进一步提升速度，特别是在表体积很大的情况下。
在完成从 SQL Server 到 Aurora MySQL 的全加载创建后，下一步是从 Aurora MySQL 到 SQL Server 回滚数据库创建全加载副本。任务完成后，我们即在源数据库、Aurora MySQL 以及 SQL Server 回滚数据库之间完成了全加载数据同步。
在这一步中，我们将向 Aurora MySQL 与 SQL Server 回滚数据库添加索引与外键，向 Aurora MySQL 添加读取节点，并将回滚数据库添加至 Always On 数据库。通过这些操作，我们的全加载性能将有所提升，同时保证数据库在切换完成之前始终处于高可用性状态。
大家当然可以在全加载期间启用验证，但如果您接下来打算使用变更数据捕捉（CDC），这里提醒大家在CDC阶段再启用验证效果更好。DMS 负责对整体数据进行验证，其中包括全部全加载组成部分的迁移数据。DMS 提供一项特殊功能，允许用户在其中设置定制化验证功能。我们会大量使用此项功能以验证各特殊字符与 Blob 数据类型。
作为质量检查（QA）流程中的一部分，我们对部分重要工作流者做了验证。我们在全加载后进行了一轮示例数据验证，希望确保关键工作流能够按预期正常运作。此项示例数据验证以 DMS 验证为基础。经过全面测试之后，我们开始进入 CDC 阶段，将全加载之后累积的增量变更从源数据库传输至 Aurora MySQL，再将 Aurora MySQL 传输至 SQL Server 回滚数据库。
在此期间，DMS 会将迁移指标发送至CloudWatch。若需了解更多详细信息，请参阅监控 Amazon Web Services DMS 任务。
在 CDC 执行期间，我们一直在密切监控 CloudWatch 中的以下几项指标：
- ValidationPendingOverallCount
- CDCLatencySource
- CDCLatencyTarget
在 ValidationPendingOverallCount 达到低值，而源数据库与目标数据库之间的 CDC 延迟最低时，我们即可着手执行数据库切换。数据库切换同样分几个步骤，我们首先需要停止应用程序的写入流量、等待挂起记录得到全部验证，而后切换应用程序中的标记以使其指向 Aurora MySQL。
上述指标的最佳数值，取决于您的实际用例与变化速度。大家可能需要通过多轮测试以确定具体数值。
以下示例图为 ValidationPendingOverallCount 指标。大家可以看到初始挂起行数很高，之后逐渐减少。
以下示例图为 CDCLatencySource 指标，它显示的是源数据库最后捕捉到的事件与 DMS 实例当前系统时间戳之间的间隔（单位为秒）。如果因任务作用域导致未能从源数据库处捕捉到任何变更，则 DMS 会将此值设置为 0。
以下示例图为 CDCLatencyTarget 指标，它显示的是 Aurora MySQL 上首个等待提交的事件时间戳与 Amazon Web Services DMS 实例当前时间戳之间的间隔（单位为秒）。如此出现此值，则意味着存在 Aurora MySQL 无法处理的事务。因为如果所有事务都得到正常应用，那么目标数据库延迟应该与源数据库延迟相同。目标数据库延迟不得低于源数据库延迟。
在本步当中，我们的应用程序已经指向 Aurora MySQL 并保持良好运行。我们的团队对应用程序进行了端到端测试，旨在确保所有功能都可正常工作。整个回滚设置共运行数天，帮助我们观察其实际运行状态。
在这一步中，我们删除了回滚设置。下图所示为我们构建完成的迁移后架构。
在这一步中，我们的目标是在最糟糕的情况下制定备份计划。由于数据库在关键任务服务中扮演重要角色，因此我们必须引入完善的回滚机制以从最坏的情况中恢复正常。
如果在发生故障时仍必须使用当前数据库，我们的计划是首先停止向 Aurora 写入流量，等待挂起记录得到验证，而后将应用程序切换至回滚数据库 SQL Server Always On）。如此一来，我们就可以在不丢失任何数据的前提下还原至旧有设置。
当然，要保证回滚设置正常起效，我们必须对其进行充足的测试与验证。我们在测试环境中使用生产规模的数据以执行测试，并确保当应用程序从 Aurora MySQL 切换至回滚数据库时，不会导致任何数据丢失问题。
我们从迁移前与迁移后的读写查询中，捕捉到前 10 条查询性能进行比较。
下图所示，为前 10 条读取查询的查询性能。可以看到，Aurora 的性能表现相当出色。
下图所示为前 10 科写入查询的查询性能。Aurora MySQL 在这里的性能表现同样胜过 MSSQL，执行时长也远低于 MSSQL。
除了之前章节中提到的方法，我们还为大家整理出以下建议：
- 充分规划运行测试，这样您才能总结出适合现有数据库的迁移策略。绝不存在百试百灵的策略，因此请务必拿出自己的配置思路并逐步做出优化。
- 进行多轮性能测试以实现 SQL 查询调优；SQL 查询在不同的数据库上会表现出不同的行为。
- 最大限度提升迁移流程的自动化水平。在实践中，我们使用 Terraform 实现自动化，从而快速重复多轮测试并总结出统一的迁移执行流程。
- 尽可能设置警报机制，同时通过适当监控以分析迁移流程。
- 为了预留充足的时间以处理意外错误，理想的作法是至少在计划切换的一天之内实现数据库切换点（详见迁移步骤中的第四步）。
异构数据库的迁移工作往往困难重重，但凭借 Amazon Web Services DMS 的协助以及妥善规划，Autodesk 仍然顺利从 SQL Server 迁移到了 Aurora MySQL。通过此轮迁移，该公司不断显著提升了运营效率，同时也对基础设施的成本与性能做出优化。