重要注意事项：如何将Amazon RDS与Amazon Aurora数据库迁移至Graviton2

原文链接：

https://aws.amazon.com/cn/blogs/database/key-considerations-in-moving-to-graviton2-for-amazon-rds-and-amazon-aurora-databases/

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

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

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

为什么选择Graviton2？

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

Graviton2实例可根据具体数据库引擎、版本及工作负载，为RDS开源数据库提供最高达52%的性能价格比提升。
与第一代AWS Graviton处理器相比，Graviton2实例的性能提高达7倍、计算核心数量增加至4倍、单核心独立缓存增加2倍、内存容量增加了5倍、浮点性能则提升2倍。
Graviton2处理器提供始终启用的全加密DDR4内存，且单核心加密性能提升达50%。
在将Amazon RDS与Aurora数据库由英特尔架构迁移至Graviton2实例时，大家无需进行任何移植或代码变更。

解决方案概述

无论是对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，而后通过验证测试确保一切均按预期完成配置及运行。

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

更新数据库（如果需要）：
- 确定当前数据库版本是否符合迁移至Graviton2所需要的最低版本。
- 将数据库引擎升级至所需的最低版本。
修改实例类：
- 确定您的修改策略以及对实例的修改顺序。
- 将您的实例类修改为适当的Graviton2实例。
验证并确认应用程序是否正常运行。
回滚（如果需要）。

升级数据库

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

确定数据库版本

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

	MySQL	PostgreSQL	MariaDB
Amazon RDS	8.0.17或更高版本	13, 12.3或更高版本	10.5与10.4.13或更高版本
Amazon Aurora	2.09.2或更高版本	12.4或更高版本及11.9或更高版本	—-

对于本文中的用例，我们使用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，我们可以遵循以下步骤实现数据库引擎版本升级：

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

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

修改实例

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

确定修改策略以及各实例的修改顺序。
将您的实例类修改为适当的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控制台。按照计划，我们首先在读取副本上修改实例类。

在Amazon RDS控制台的导航窗格中，选择Databases。
选择读取实例（在本文中，我们使用 auroralab-pgsql-node-3) 而后选择 Modify。
在DB instance class size部分，选择 Memory Optimized类。
选择您的实例类；在本文中，我们选择db.r6g.large（其中的「g」代表Graviton2）。

选择Continue。
在摘要页面上，查看变更内容。
要立即应用变更，请选择Apply immediately。如果您不立即应用变更，则变更内容将在您所设定的首选维护时段内进行。在某些情况下，选择立即应用可能会导致服务中断。
选择 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层。

选择auroralab-pgsql-node-2 实例，之后选择 Modify。
在Failover priority部分，选择 tier-2。

选择Continue。
选择Modify DB instance。

执行故障转移

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

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

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

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

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

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

回滚

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

如果您的集群中存在一个x86读取实例，则可通过调整故障转移优先级故障转移至集群内的另一x86实例。
您还可以按照本文之前提到的类似过程，将实例类型变更回x86实例类型。
如果问题仍然存在，则可以使用变更之前保存的快照进行还原。关于使用Amazon RDS或Aurora时的其他注意事项，请分别参阅从数据库快照还原与从数据库集群快照还原。

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

总结

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

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

扩展资源

关于更多信息及其他资源，请参见以下内容：

亚马逊AWS官方博客