亚马逊AWS官方博客

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

原文链接:

https://thinkwithwp.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 MySQLAmazon RDS for PostgreSQLAmazon 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迁移所要求的最低版本,本文还简要介绍了数据库升级过程。

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

 

扩展资源

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

 

本篇作者

Reagan Rosario

亚马逊云科技解决方案架构师,专注于教育科技方向。他喜欢帮助客户在AWS云中构建起可扩展、高度可用且安全可靠的解决方案。

Tyler Lynch

亚马逊云科技高级解决方案架构师,专注于教育科技方向。他对教育及终身学习始终充满热情。