如何将 Amazon RDS 与 Amazon Aurora 数据库迁移至 Graviton2？

2021 年 12 月 21 日
本文字数：5992 字
阅读完需：约 20 分钟

Amazon Relational Database Service (Amazon RDS) 与 Amazon Aurora 支持多种实例类型，可根据您的实际需求扩展数据库工作网域（请分参见文末参考资料中 Amazon RDS 数据库实例类与 Aurora 数据库实例类）。2020 年，亚马逊云科技公布面向 Amazon RDS 的全新 M6g 及 R6g 实例类型，又于日前宣布正式推出搭载 Amazon Graviton2 处理器的 Aurora R6g 实例类型。值得一提的是，这种全新实例类型拥有远超 x86 同类产品的性价比。

Graviton2 处理器由亚马逊云科技使用 64 位 ARM Neoverse 核心定制构建而成，相较于第一代 Amazon Gravtion 处理器做出了多项优化。您可以通过 Amazon RDS 控制台或 Amazon 命令行界面（Amazon CLI）启动新的 Graviton2 M6g 与 R6g 数据库实例，并以最小停机时间将多可用区数据库迁移至 Gravtion2 实例，尽可能避免因迁移造成的 I/O 冻结影响到正常服务。

在本文中，我们将共同了解将现有 RDS 与 Aurora 数据库实例转为 Graviton2 实例类时的重要注意事项，包括应配合哪些先决条件及具体策略以尽量缩短停机时间。

为什么选择 Graviton2？

以下是将 Amazon RDS 与 Amazon Aurora 迁移至 Graviton2 的几大核心理由：

1.Graviton2 实例可根据具体数据库引擎、版本及工作负载，为 RDS 开源数据库提供最高达 52%的性能价格比提升。

2.与第一代 Amazon Graviton 处理器相比，Graviton2 实例的性能提高达 7 倍、计算核心数量增加至 4 倍、单核心独立缓存增加 2 倍、内存容量增加了 5 倍、浮点性能则提升 2 倍。

3.Graviton2 处理器提供始终启用的全加密 DDR4 内存，且单核心加密性能提升达 50%。

4.在将 Amazon RDS 与 Aurora 数据库由英特尔架构迁移至 Graviton2 实例时，大家无需进行任何移植或代码变更。

📢 想学习 Graviton2 实例的更多玩法？来 2021 亚马逊云科技中国峰会与业内领先的技术践行者们一起探讨交流吧！点击图片报名吧～

解决方案概述

无论是对 Amazon RDS (Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon RDS for MariaDB) 还是 Aurora (Aurora MySQL 与 Aurora PostgreSQL)，整个实例迁移流程的基本步骤都大致相同。

在本文中，我们假定这样一个用例，即一套运行有 PostgreSQL 9.6.16 版本的多可用区 Aurora 数据库集群，其中包含三个实例：一个写入实例与两个读取实例。

结合常规最佳实践，我们建议先在非生产环境中测试整个流程。您可以首先使用生产数据库的快照，而后将其还原至这套非生产环境的实例当中，确保测试实例的配置（包括实例类、参数组设置、加密机制等）与现有生产实例基本相同。接下来，将您的非生产实例修改为 Graviton2，而后通过验证测试确保一切均按预期完成配置及运行。

下面来看整个流程中的各主要步骤：

1.更新数据库（如果需要）：

确定当前数据库版本是否符合迁移至 Graviton2 所需要的最低版本。

将数据库引擎升级至所需的最低版本。

2.修改实例类：

确定您的修改策略以及对实例的修改顺序。

将您的实例类修改为适当的 Graviton2 实例。

3.验证并确认应用程序是否正常运行。

4.回滚（如果需要）。

升级数据库

这是一个可选步骤，只适用于当前数据库版本达不到 Graviton2 迁移所需要的最低版本时才需使用。因此，请首先确定您是否有必要升级数据库版本。

确定数据库版本

下表所示，为截至本文撰稿时 Graviton2 所支持的各数据库版本；表中列出的均为经过编译或开发，且在测试中能够确切兼容 Graviton2 的数据库版本。

对于本文中的用例，我们使用 Aurora PostgreSQL 8.6.16 版本，此版本低于迁移至 Graviton2 的最低必要版本。

关于最新更新信息，请参阅文末参考资料关于数据库实例类所支持的数据库引擎（Amazon RDS）与数据库实例类所支持的数据库引擎（Aurora）。

如果您的数据库并非 Graviton2 所支持的版本，则需要升级至受支持版本。要获取当前源版本所能使用的全部升级版本清单，请使用 describe-db-engine-versions CLI 命令。

在 Linux、MacOS 与 Unix 系统中，请使用以下代码：

aws rds describe-db-engine-versions  --engine aurora-postgresql  --engine-version 9.6.16 --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`]'

复制代码

在 Windows 系统中，请使用以下代码：

aws rds describe-db-engine-versions  --engine aurora-postgresql  --engine-version 9.6.16 --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`]"

复制代码

以下截屏所示，为基于 Linux 的操作系统中的命令输出结果。其中包含目标版本的 ValidUpgradeTarget 数组的值。

如果 IsMajorVersionUpgrade 的值为 true，则可以将主版本升级至相关的 EngineVersion。如果数组为空，则无法进行主要版本升级。您必须首先升级至主要版本，而后才能进一步升级至路径内的次要版本。

将数据库升级至最低必要版本

在某些情况下，我们可能无法由当前数据库版本直接升级至 Graviton2 所支持的最低数据库版本。对于本文中的用例，我们使用的是 Aurora PostgreSQL 9.6.16 版本，而 Graviton2 支持的最低版本为 11.9。由于不存在由 9.6 直接升级至 11.9 的路径，因此我们需要首先由 9.6.16 升级至 10.14，再进一步升级至 11.9。因此，这里需要完成两步走升级流程。

对于 Amazon RDS，我们可以遵循以下步骤实现数据库引擎版本升级：

1.对 Amazon RDS 的 MySQL 数据库引擎进行升级:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html

2.对 Amazon RDS 的 PostgreSQL 数据库引擎进行升级：

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html

3.对 Amazon RDS 的 MariaDB 数据库引擎进行升级：

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.html

对于 Aurora，大家可以遵循以下步骤实现数据库引擎版本升级：

1.对 Amazon Aurora 的 MySQL 数据库引擎进行升级：

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Upgrading.html

2.对 Amazon Aurora 的 PostgreSQL 数据库引擎进行升级：

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html

如果您希望尽可能缩短停机时间，则可以配合 Amazon Database Migration Service (Amazon DMS)使用另一种升级方法。关于更多细节信息，请参阅使用 Amazon DMS 在 Amazon Aurora for PostgreSQL 中以最短停机时间进行主版本升级：

https://aws.amazon.com/blogs/database/achieving-minimum-downtime-for-major-version-upgrades-in-amazon-aurora-for-postgresql-using-aws-dms/

修改实例

要修改实例，大家需要完成以下操作步骤：

1.确定修改策略以及各实例的修改顺序。

2.将您的实例类修改为适当的 Graviton2 实例。

确定您的策略

您所选择的实例类修改策略，具体取决于您的实际配置——例如采用多可用区或读取副本。

对于采用多可用区设置的 Amazon RDS，所有实例修改均在辅助实例上完成，而后执行故障转移。接下来，在新的辅助（即原主）实例上重复修改步骤。这种方法带来的停机时间仅限于故障转移周期。故障转移周期通常为 60 到 120 秒。在实例类修改期间，单可用区实例将不可用。

对于采用一个或多个 Aurora 副本的 Aurora，在我们修改写入实例时，将有一套 Aurora 副本被升级为主实例；接下来在这个新的 Aurora 副本（原写入实例）上继续修改。临时中断一般在 120 秒以内。为了最大程度降低停机时间与风险，您可以首先在 Aurora 副本上修改实例，验证其是否按您的预期方式运行，而后通过故障转移迁移至现有 Graviton2 读取实例。在您的 Aurora 集群中，大家可以按照与具体用例相匹配的任意顺序将各实例修改为 Graviton2。

您还可以将 Graviton2 R6g 与 Intel R5 实例混合使用并匹配在同一集群当中，作为您的主实例或者读取副本，借此根据工作负载的需求尽可能提高实例资源性价比。

实例类的变更，意味着该实例将被重新定位至另一硬件主机之上，原有缓冲区也将不复存在。因此，当所修改的实例上的数据库重新启动时，缓冲区将处于冷启动状态，所以初始查询可能需要更长的时间。

作为一项常规最佳实践，我们可以在修改之前保存手动快照以保证能够轻松回滚。对于在单可用区设置内的 Amazon RDS，保存快照的过程（持续几秒到几分钟）内所有 I/O 将被挂起，具体视数据量大小而定。在多可用区配置下，快照保存期间不会导致 I/O 挂起。对于 Aurora，保存快照不会影响性能或导致数据库服务中断。

最好能根据您的日程安排，在 Amazon RDS 维护时段之内规划这项变更。这里指的是每周维护时段，即专门用于应用系统变更的时间窗口。您可以将维护窗口视为良好的调整机会，抓紧在此期间调整控制机制、进行软件修复。

对于本文中的用例，我们首先将一个 Aurora 读取实例迁移至 Graviton2，而后进行验证以确保其正常工作。我们将读取实例类修改为 Graviton2，而后故障转移至这个新的 Graviton2 读取实例并将其提升为写入实例。故障转移过程一般只需要几秒即可完成。

修改实例类

我们首先登录至 Amazon RDS 控制台。按照计划，我们首先在读取副本上修改实例类。

1.在 Amazon RDS 控制台的导航窗格中，选择 Databases。

2.选择读取实例（在本文中，我们使用 auroralab-pgsql-node-3)而后选择 Modify。

3.在 DB instance class size 部分，选择 Memory Optimized 类。

4.选择您的实例类；在本文中，我们选择 db.r6g.large（其中的「g」代表 Graviton2）。

5.选择 Continue。

6.在摘要页面上，查看变更内容。

7.要立即应用变更，请选择 Apply immediately。如果您不立即应用变更，则变更内容将在您所设定的首选维护时段内进行。在某些情况下，选择立即应用可能会导致服务中断。

8.选择 Modify DB instance。

以下截屏所示，为当前正在修改的实例。

对于本文中的用例，读取副本实例的修改时间耗费了几分钟。在修改此实例时，系统将打开写入实例及另一读取实例以处理应用请求。数据集的大小或数据库的加密状态等图中并未显示的因素，会影响到修改实例类所需要的时间。

以下截屏所示，为位于 db.r5.large（x86）实例上的一个写入加一个读取副本，另一读取副本位于 db.r6g.large（Graviton2）实例上。

现在，我们将写入副本故障转移至新的 db.r6g.large 读取副本。每个读取副本都对应一项优先级。在执行故障转移时，Amazon RDS 会首先提升优先级最高（层级数值最小）的读取副本。如果两个或更多副本拥有相同的优先级，则 Amazon RDS 将优先提升与原有主实例大小相同的副本。在进行故障转移之前，我们需要保证 db.r6g.large 读取副本的故障转移在优先级上高于其他读取副本。默认情况下，它们都位于第 1 级，因此我们需要选择 auroralab-pgsql-node-2 读取副本并将其配置变更为第 2 层。

9.选择 auroralab-pgsql-node-2 实例，之后选择 Modify。

10.在 Failover priority 部分，选择 tier-2。

11.选择 Continue。

12.选择 Modify DB instance。

执行故障转移

在 Action 菜单上选择写入实例 auroralab-pgsql-node-1，之后选 Failover。

如果使用集群端点（推荐）而非数据库端点进行连接，并采用连接重试逻辑，则可以将应用程序的服务中断周期缩短至最低程度。在故障转移期间，Amazon 会修改集群端点 DNS 以指向新创建或新提升的数据库实例。变更完成之后，您将获得一个运行在 Graviton2 之上的写入实例。

为了尽可能减少服务中断并增强应用程序弹性，您还可以使用 Amazon RDS 代理。要进一步缩短故障转移周期，您也可以在应用程序层级上配置主动 TCP keepalive 与 JDBC 连接设置或者 PGConn 类。关于更多细节信息，请参阅 Amazon Aurora PostgreSQL 最佳实践:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/AuroraPostgreSQL.BestPractices.html

验证并确认应用程序正常运行

现在，您可以验证应用程序是否能够与基于 Graviton2 的 RDS 或 Aurora 数据库协同工作。如果启用了 Performance Insights，则可以使用 Performance Insights 仪表板实现数据库负载可视化，并根据等待时长、SQL 语句、主机或用户对负载进行筛选。

经过一段时间的测试（可能需要几天时间，具体视您的需求而定），您可以将其余读取实例变更为 Graviton2，并删除变更之前保存的快照。

回滚

在完成任意变更之后，如果发现新变更无法起到预期的效果，您必须设有后备策略——这一点非常重要。从宏观层面来看，大家拥有以下几种选择：

1.如果您的集群中存在一个 x86 读取实例，则可通过调整故障转移优先级故障转移至集群内的另一 x86 实例。

2.您还可以按照本文之前提到的类似过程，将实例类型变更回 x86 实例类型。

3.如果问题仍然存在，则可以使用变更之前保存的快照进行还原。关于使用 Amazon RDS 或 Aurora 时的其他注意事项，请参阅文末参考资料中从数据库快照还原与从数据库集群快照还原。

回滚过程本身属于单独的主题，受篇幅所限，本文不再讨论更多具体细节。

总结

本文分步向大家介绍如何将 Aurora PostgreSQL 实例修改为 Graviton2，并强调了关于停机时间控制方面的重要注意事项。您可以按照类似的步骤将 RDS 实例修改为 Graviton2。如果您的数据库版本未能达到 Graviton2 迁移所要求的最低版本，本文还简要介绍了数据库升级过程。

作为最佳实践，您应始终在较低环境中测试各项变更，包括您可能需要的数据库扩展，同时保证测试环境在配置与规模方面与生产环境高度相似。