共计 6915 个字符，预计需要花费 18 分钟才能阅读完成。
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
亚马逊云科技高级解决方案架构师
专一于教育科技方向。他对教育及一生学习始终充满热情。
