关于data:如何将Amazon-RDS与Amazon-Aurora数据库迁移至Graviton2

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/A...

2.对Amazon RDS的PostgreSQL数据库引擎进行降级：
https://docs.aws.amazon.com/A...

3.对Amazon RDS的MariaDB数据库引擎进行降级：
https://docs.aws.amazon.com/A...

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

1.对Amazon Aurora的MySQL数据库引擎进行降级：
https://docs.aws.amazon.com/A...

2.对Amazon Aurora的PostgreSQL数据库引擎进行降级：
https://docs.aws.amazon.com/A...

如果您心愿尽可能缩短停机工夫，则能够配合Amazon Database Migration Service (Amazon DMS)应用另一种降级办法。对于更多细节信息，请参阅应用Amazon DMS在Amazon Aurora for PostgreSQL中以最短停机工夫进行主版本升级：

https://aws.amazon.com/blogs/...

批改实例

要批改实例，大家须要实现以下操作步骤：

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/A...

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

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

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

回滚

在实现任意变更之后，如果发现新变更无奈起到预期的成果，您必须设有后备策略——这一点十分重要。从宏观层面来看，大家领有以下几种抉择：

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

2.您还能够依照本文之前提到的相似过程，将实例类型变更回x86实例类型。

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

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

总结

本文分步向大家介绍如何将Aurora PostgreSQL实例批改为Graviton2，并强调了对于停机工夫管制方面的重要注意事项。您能够依照相似的步骤将RDS实例批改为Graviton2。如果您的数据库版本未能达到Graviton2迁徙所要求的最低版本，本文还简要介绍了数据库降级过程。

作为最佳实际，您应始终在较低环境中测试各项变更，包含您可能须要的数据库扩大，同时保障测试环境在配置与规模方面与生产环境高度类似。

参考资料

Amazon Relational Database Service:
https://aws.amazon.com/rds/

Amazon Aurora:
https://aws.amazon.com/rds/au...

Amazon RDS数据库实例类:
https://docs.aws.amazon.com/A...

Aurora数据库实例类:
https://docs.aws.amazon.com/A...

Amazon RDS for MySQL：
https://aws.amazon.com/rds/my...

Amazon RDS for PostgreSQL：
https://aws.amazon.com/rds/po...

Amazon RDS for MariaDB：
https://aws.amazon.com/rds/ma...

Aurora MySQL：
https://aws.amazon.com/rds/au...

Aurora PostgreSQL：
https://aws.amazon.com/rds/au...

数据库实例类所反对的数据库引擎：
https://docs.aws.amazon.com/A...

数据库实例类所反对的数据库引擎：
https://docs.aws.amazon.com/A...

describe-db-engine-versions：
https://docs.aws.amazon.com/c...

Amazon Database Migration Service：
https://aws.amazon.com/dms/

本篇作者

Reagan Rosario
亚马逊云科技解决方案架构师

专一于教育科技方向。他喜爱帮忙客户在亚马逊云科技云中构建起可扩大、高度可用且安全可靠的解决方案。

Tyler Lynch
亚马逊云科技高级解决方案架构师

专一于教育科技方向。他对教育及一生学习始终充满热情。