亚马逊AWS官方博客
Autodesk 的核心业务数据库迁移之路：从微软 SQL Server 到 Amazon Aurora MySQL
Autodesk公司多年之前就已经启动了自己的云计算现代化之旅，着手将工作负载从本地数据中心迁移至Amazon EC2及其他AWS服务当中。Autodesk之所以积极推进现代化改造，自然是为了获取必要的灵活性与可扩展性，支持业务的预期增长。2019年，该公司将其关键任务单点登录（SSO）应用从EC2上的自托管SQL Server中迁移至全托管Amazon Aurora MySQL。此项服务需要应对全球各地超过1.42亿用户的身份验证请求，每分钟API请求响应数量超过14万5千次。此外，该应用还整合了300多种用于实现身份验证与授权操作的产品及服务。
此次迁移有助于简化Autodesk SSO服务的管理与弹性、优化运营成本并降低基础设施的维护开销。根据初步成本分析结果，该公司在使用Amazon Aurora MySQL之后每月总体数据库成本可下降约40%至50%。
通过本文，我们将探讨Autodesk公司如何在尽可能缩短停机时间的前提下，对关键任务数据库进行迁移。以下各章节将分别介绍迁移前架构、迁移策略、迁移步骤以及性能比较等相关议题。
迁移前架构
下图所示，为Autodesk以往使用的SQL Server架构。该数据库以自托管形式在EC2实例之上运行，且跨越多个可用区与另一区域内的单一节点建立起Always On机制，借此实现灾难恢复能力。
随着时间推移，Autodesk团队发现现有配置中存在以下挑战：
- 中断——以往发生的诸多中断事件，正是由于这套复杂的自找托管数据库基础设施所导致。整个体系中涉及多个采用Amazon EBS加RAID 10存储配置的EC2实例，结果就是Windows Server故障转移集群（WSFC）、存储以及IOPS等众多元素构成极为复杂的分层体系。更重要的是，运营团队越来越难以对事件根源进行分析与追溯。
- 备份——管理备份也带来可观的开销，特别是在跨区域设置层面。尽管我们使用了自动化脚本，但整个备份流程仍然需要人为介入与严格监控。
- 补丁修复——由于Autodesk公司拥有多个环境（包括测试环境、暂存环境与生产环境），因此补丁修复消费了管理员们大量宝贵的时间。
- 可扩展性——主节点负责填写只读路由请求，同时标记需要接入的辅助节点。尽管此功能能够保证连接始终被路由至运行状态良好的辅助节点，但从可扩展性的角度来看，主节点的存在本身即是最大的瓶颈。
- 副本数量——SQL Server最多允许设置8个辅助副本，而Aurora MySQL最多可支持15个副本。
- 成本——原本的总体拥有成本，达到迁移至Aurora之后新体系的两倍。
- 弹性——对基础设施进行规模伸缩需要耗费大量时间。
迁移策略
我们从概念验证起步，借此确定需要完成的应用程序变更、数据库变更、脚本自动化以及各类预创建服务。更重要的是，我们还借此确定迁移至Aurora这一举措能够有效解决前面提到的种种挑战。
在实施必要的变更之后，我们制定了计划，以分阶段方式迁移至不同环境。以此为基础，我们对策略进行微调，逐步明确了在不同环境上运行迁移时所带来的相应停机时间。我们的目标是在最少的停机时长之内完成迁移。为了在不同环境间灵活高效地实现迁移，我们利用Terraform自动执行数据库创建与DMS配置等步骤。当然，大家也可以使用AWS CloudFormation实现相同的自动化效果。
在以下章节中，我们将具体探讨迁移过程中的各注意事项。
Schema迁移
AWS Schema转换工具 是一款出色的schema迁移工具，能够将迁移工作量控制在最低水平。但在本示例中，由于存在大量定制化需求，我们只能放弃效率、选择更适合的schema转换方法。
作为schema转换流程中的一部分，我们首先为数据库选择了最佳字符集。如此一来，我们的数据库体积将缩减到原始大小的三分之一左右。对数据库的成功“瘦身”，将在迁移过程中带来巨大助益。
在确定目标数据库的最终架构之前，我们需要全面评估以下因素：
- 字符集与排序规则
- 数据类型选择
- 日期/时间模式
- 多字节字符存储
- 特殊字符存储
- 索引类型
这些注意事项不仅有助于数据迁移，同时也将避免因引入特殊数据集而导致的各类迁移后问题。
容量规划
我们对容量规划进行了广泛测试，包括迭代运行工作负载以确定合适的实例大小与对应容量。此外，我们还比较了来自各类监控工具（例如Amazon CloudWatch、New Relic以及MonYog）的关键指标、分析慢查询日志，并对现有生产工作负载/流量及未来数据增长做出预测。
应用程序迁移
应用程序迁移将以无缝化形式进行，因为我们使用NHibernate（ORM）进行数据访问。ORM生成约80%的查询比例，因此我们可以在应用程序内以最少的ORM配置变更生成MySQL查询。这里也建议大家首先观察应用程序通过ORM生成了多少查询，并据此估算转换其余查询所需要的具体工作量。
我们在SSO应用程序中开发了一项功能，用于支持按需数据库连接切换并进一步实现对读取/写入流量的控制。以此为基础，我们能够在整个迁移计划中实现连续部署与跨环境执行。最后，这项举措还有助于最大程度减少数据库切换操作所带来的停机时间。
之前，我们使用的是完整.NET框架，遗憾的是带有NHibernate的.NET完整框架中的MySQL驱动程序并不支持Aurora MySQL故障转移功能。换句话说，我们的应用程序将无法自行实现故障恢复。为此，我们提出了一项自定义解决方案，针对.NET中MySQL驱动程序缺失的问题为Aurora MySQL故障转移提供新的支持方法，确保应用程序能够在迁移过程中继续正常支持业务流量。
数据迁移
数据迁移与验证是整个迁移流程中的重要一步。我们使用AWS DMS以实现安全且经济的迁移效果。关于更多详细信息，请参阅AWS Database Migration Service上手指南。
迁移步骤
下图所示，为迁移中的各项状态与具体步骤。图中为前滚迁移模式，各个步骤将帮助大家快速理解与迁移进度相关的情况。在下面几个章节中，我们将就每种状态及其内容做出说明。
只要可能，我们都会提前创建服务与基础设施。例如，在开始迁移之前，我们的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。若需了解更多详细信息，请参阅监控AWS DMS任务。
第四步
在CDC执行期间，我们一直在密切监控CloudWatch中的以下几项指标：
- ValidationPendingOverallCount
- CDCLatencySource
- CDCLatencyTarget
在ValidationPendingOverallCount达到低值，而源数据库与目标数据库之间的CDC延迟最低时，我们即可着手执行数据库切换。数据库切换同样分几个步骤，我们首先需要停止应用程序的写入流量、等待挂起记录得到全部验证，而后切换应用程序中的标记以使其指向Aurora MySQL。
上述指标的最佳数值，取决于您的实际用例与变化速度。大家可能需要通过多轮测试以确定具体数值。
以下示例图为 ValidationPendingOverallCount指标。大家可以看到初始挂起行数很高，之后逐渐减少。
以下示例图为CDCLatencySource指标，它显示的是源数据库最后捕捉到的事件与DMS实例当前系统时间戳之间的间隔（单位为秒）。如果因任务作用域导致未能从源数据库处捕捉到任何变更，则DMS会将此值设置为0。
以下示例图为CDCLatencyTarget指标，它显示的是Aurora MySQL上首个等待提交的事件时间戳与AWS DMS实例当前时间戳之间的间隔（单位为秒）。如此出现此值，则意味着存在Aurora MySQL无法处理的事务。因为如果所有事务都得到正常应用，那么目标数据库延迟应该与源数据库延迟相同。目标数据库延迟不得低于源数据库延迟。
第五步
在本步当中，我们的应用程序已经指向Aurora MySQL并保持良好运行。我们的团队对应用程序进行了端到端测试，旨在确保所有功能都可正常工作。整个回滚设置共运行数天，帮助我们观察其实际运行状态。
最终状态
在这一步中，我们删除了回滚设置。下图所示为我们构建完成的迁移后架构。
回滚步骤
在这一步中，我们的目标是在最糟糕的情况下制定备份计划。由于数据库在关键任务服务中扮演重要角色，因此我们必须引入完善的回滚机制以从最坏的情况中恢复正常。
如果在发生故障时仍必须使用当前数据库，我们的计划是首先停止向Aurora写入流量，等待挂起记录得到验证，而后将应用程序切换至回滚数据库SQL Server Always On）。如此一来，我们就可以在不丢失任何数据的前提下还原至旧有设置。
当然，要保证回滚设置正常起效，我们必须对其进行充足的测试与验证。我们在测试环境中使用生产规模的数据以执行测试，并确保当应用程序从Aurora MySQL切换至回滚数据库时，不会导致任何数据丢失问题。
性能比较
我们从迁移前与迁移后的读写查询中，捕捉到前10条查询性能进行比较。
下图所示，为前10条读取查询的查询性能。可以看到，Aurora的性能表现相当出色。
下图所示为前10科写入查询的查询性能。Aurora MySQL在这里的性能表现同样胜过MSSQL，执行时长也远低于MSSQL。
相关建议
除了之前章节中提到的方法，我们还为大家整理出以下建议：
- 充分规划运行测试，这样您才能总结出适合现有数据库的迁移策略。绝不存在百试百灵的策略，因此请务必拿出自己的配置思路并逐步做出优化。
- 进行多轮性能测试以实现SQL查询调优；SQL查询在不同的数据库上会表现出不同的行为。
- 最大限度提升迁移流程的自动化水平。在实践中，我们使用Terraform实现自动化，从而快速重复多轮测试并总结出统一的迁移执行流程。
- 尽可能设置警报机制，同时通过适当监控以分析迁移流程。
- 为了预留充足的时间以处理意外错误，理想的作法是至少在计划切换的一天之内实现数据库切换点（详见迁移步骤中的第四步）。
总结
异构数据库的迁移工作往往困难重重，但凭借AWS DMS的协助以及妥善规划，Autodesk仍然顺利从SQL Server迁移到了Aurora MySQL。通过此轮迁移，该公司不断显著提升了运营效率，同时也对基础设施的成本与性能做出优化。
Autodesk以及其他众多企业已经开始享受Amazon Aurora MySQL带来的种种助益，您的基础设施现代化与转型规划提上议程了吗？
本篇作者