Key considerations in moving to Graviton2 for Amazon RDS and Amazon Aurora databases

Amazon Relational Database Service (Amazon RDS) and Amazon Aurora support a multitude of instance types for you to scale your database workloads based on your needs (see Amazon RDS DB instance classes and Aurora DB instance classes, respectively). In 2020, AWS announced Amazon M6g and R6g instance types for Amazon RDS and recently announced the general availability of R6g instance type for Aurora powered by AWS Graviton2 processors, which offers a better cost-performance ratio compared to their x86 counterparts.

Graviton2 processors are custom built by AWS using 64-bit Arm Neoverse cores, and deliver several optimizations over first-generation AWS Graviton processors. You can launch new Graviton2 M6g and R6g database instances via the Amazon RDS console or the AWS Command Line Interface (AWS CLI). You can move Multi-AZ databases to Graviton2 with minimal downtime, suspending I/O for the duration of a failover.

In this post, we discuss key considerations when modifying existing RDS and Aurora DB instances to Graviton2 based instance types. We discuss the prerequisites and different strategies that you can take to reduce downtime.

Why move to Graviton2?

The following are some of the reasons for moving to Graviton2 for Amazon RDS and Amazon Aurora:

Graviton2 instances provide up to 52% price/performance improvement for RDS open-source databases depending on database engine, version, and workload. They also provide up to 35% price/performance improvement for Aurora depending on database size.
Graviton2 instances provide seven times the performance, four times the number of compute cores, two times larger private caches per core, five times faster memory, and two times faster floating-point performance per core over the first-generation AWS Graviton processors.
Graviton2 processors feature always-on fully encrypted DDR4 memory and 50% faster per core encryption performance.
No porting or code changes are required when migrating from Intel to Graviton2 instances on Amazon RDS and Aurora.

Solution Overview

The steps that you take for modifying your instance type is similar for both Amazon RDS (Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon RDS for MariaDB) and Aurora (Aurora MySQL and Aurora PostgreSQL).

For this post, let’s consider a use case in which we have a Multi-AZ Aurora database cluster at PostgreSQL version 9.6.16 with three instances: one writer and two readers.

As a general best practice, it’s recommended to test the process in a non-production environment. You can start by using a snapshot of your production database and restoring it into an instance in your non-production environment, which has a similar configuration (instance class, parameter group settings, encryption) as the current production instance. Then modify your non-production instance to Graviton2 followed by validation tests to make sure everything is configured and operating as per your expectations.

The high-level steps in the process are as follows:

Upgrade the database (if necessary):
1. Determine if the current database version meets the minimum required version for moving to Graviton2.
2. Upgrade the database engine to the required minimum version.
Modify the instance types:
1. Determine your strategy and the order in which to modify your instances.
2. Modify the instance class of your instances to the appropriate Graviton2 instance.
Validate and confirm that the application works correctly.
Rollback (if required).

Upgrade the database

This is an optional step and only required if the current database version does not meet the minimum required version for moving to Graviton2, so we start by determining if we need to upgrade the database version.

Determine the database version

The following table shows the supported versions for Graviton2 as of this post; these are the versions of the database that were compiled or developed and tested to be compatible with Graviton2.

	MySQL	PostgreSQL	MariaDB
Amazon RDS	8.0.17 and higher	12.3, 13 and higher	10.4.13, 10.5 and higher
Amazon Aurora	2.09.2 and higher	11.9 and higher, 12.4 and higher	—-

For our use case in this post, we use Aurora PostgreSQL version 9.6.16, which is lower than the version required to move to Graviton2.

For the latest updates of this information, see Supported DB engines for DB instance classes (Amazon RDS) and Supported DB engines for DB instance classes (Aurora).

If your database isn’t at a version that is supported by Graviton2, you need to upgrade to a supported version. To get a list of all valid upgrade targets for a current source version, use the describe-db-engine-versions CLI command.

For Linux, macOS, or Unix, use the following code:

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

For Windows, use the following code:

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

The following screenshot shows the output from the preceding command in a Linux-based operating system. It shows the value of the ValidUpgradeTarget array containing the target versions.

If the IsMajorVersionUpgrade value is true, you can do a major version upgrade to the associated EngineVersion. If the array is empty, you can’t do a major version upgrade. You must first upgrade to a minor version that has a major version upgrade path.

Upgrade the database to the required minimum version

In some cases, there is no direct upgrade path from the current database version to a minimum database version supported by Graviton2. For our use case in this post, we are at version 9.6.16 of Aurora PostgreSQL, and the minimum supported version for Graviton2 is 11.9. There is no direct upgrade path from 9.6 to 11.9, so we have to first upgrade from 9.6.16 to 10.14 and only then to 11.9. So this is a two-step upgrade process.

For Amazon RDS, you can follow these steps to upgrade your database engine version:

For Aurora, you can follow these steps to upgrade your database engine version:

While upgrading, you have the option of doing an in-place upgrade, which requires downtime. If you want to minimize downtime, you can follow an alternative approach of using AWS Database Migration Service (AWS DMS). For more information, see Achieving minimum downtime for major version upgrades in Amazon Aurora for PostgreSQL using AWS DMS.

Modify the instances

To modify your instances, you complete the following high-level steps:

Determine your strategy and the order in which to modify your instances.
Modify your instance class to the appropriate Graviton2 instance.

Determine your strategy

The strategy that you choose for modifying the instance types depends on the configuration you have, such as Multi-AZ or read replicas.

For Amazon RDS with Multi-AZ, all of the instance modification is done on the secondary instance, after which failover is performed. The modification steps are then repeated on the new secondary (former primary) instance. The planned downtime duration is limited to just the failover time. Failover times are typically 60–120 seconds. A Single-AZ instance is unavailable during instance type modification.

For Aurora with one or more Aurora replicas, when you modify the writer instance, an Aurora replica is promoted to the primary instance while the modification continues on the new Aurora replica (former writer). There is a brief interruption that typically is less than 120 seconds. For minimal downtime and risk, you can modify the instance on the Aurora replica first, validate it works as per your expectations, and then fail over to the now Graviton2 reader. Within your Aurora cluster, you can modify your instances to Graviton2 in any order that is suitable for your use case.

You can also mix and match Graviton2 R6g and Intel R5 instances within the same cluster for your primary instance or for your read replica, enabling you to maximize price/performance improvements based on workload requirements.

A change of instance type means a relocation of the instance to another hardware host, which means that the buffer cache isn’t maintained. Therefore, when the database on the modified instance restarts, the buffer cache is cold and initial queries might take longer.

As a general best practice, you can take a manual snapshot before the modification to ensure easy rollback. For Amazon RDS in a Single-AZ setup, this results in suspending the I/O during the snapshot time, from a few seconds to a few minutes, depending on the size. On a Multi-AZ configuration, there’s no I/O suspension during snapshot. For Aurora, no performance impact or interruption of database service occurs.

It’s a good idea to plan the change during the Amazon RDS maintenance window based on your schedule. This maintenance window is a weekly maintenance window during which any system changes are applied. You can think of the maintenance window as an opportunity to control when modifications and software patching occur, in the event either are requested or required.

For our use case in this post, we start by moving one Aurora reader instance to Graviton2 and then run validations on it to make sure it works correctly. We modify the reader instance type to Graviton2, then fail over to this new Graviton2 reader and promote it to the writer instance. The failover process takes a few seconds to complete.

Modify the instance class of your instances

We start by signing in to the Amazon RDS console. As planned, we modify the instance class on a read replica first.

1. On the Amazon RDS console, in the navigation pane, choose Databases.
2. Select the reader instance (for this post, we use auroralab-pgsql-node-3) and choose Modify.
3. For DB instance class size, select Memory Optimized classes.
4. Choose your instance class; for this post, we choose db.r6g.large (the “g” stands for Graviton2).
5. Choose Continue.
6. On the summary page, review the changes.
7. To apply the change immediately, select Apply immediately. If you don’t apply the change immediately, the change is scheduled to occur during the preferred maintenance window that you defined. Choosing Apply Immediately can cause an outage in some cases.
8. Choose Modify DB instance.

The following screenshot shows the instance being modified.

For our use case in this post, the modification time of the read replica instance took a few minutes. While this instance is being modified, the writer instance and another reader instance are open to serve application requests. The size of the dataset or encryption status of the database has not shown to impact the time required for the instance class modification.

The following screenshot shows that one writer and one reader are at db.r5 large (x86), and one reader is at a db.r6g.large (Graviton2) instance.

We now fail over the writer to the new db.r6g.large reader. Each read replica is associated with a priority tier. In the event of a failover, Amazon RDS promotes the read replica that has the highest priority (the lowest-numbered tier). If two or more replicas have the same priority, Amazon RDS promotes the one that is the same size as the previous primary instance. Before failing over, we need to make sure that the failover priority of the db.r6g.large reader is higher than the other reader. By default they are both at tier-1, so we need to choose the auroralab-pgsql-node-2 reader and change the configuration to tier-2.

Select the auroralab-pgsql-node-2 instance and choose Modify.
For Failover priority, choose tier-2.
Choose Continue.
Choose Modify DB instance.

Perform failover

Select the writer instance auroralab-pgsql-node-1 and on the Action menu, choose Failover.

Applications experience minimal interruption of service if you connect using the cluster endpoint (recommended) instead of DB endpoints and implement connection retry logic. During the failover, AWS modifies the cluster endpoint DNS to point to the newly created or promoted DB instance. After the change, you have a writer instance running on Graviton2.

To minimize service interruptions and make applications more resilient, you can also use Amazon RDS Proxy. To further reduce failover time, you can configure aggressive TCP keepalive settings and JDBC connection settings or the PGConn class at the application level. For details, see Best Practices with Amazon Aurora PostgreSQL.

Validate and confirm that the application works correctly

You can now validate that your application works correctly with the Graviton2-based RDS or Aurora databases. If you have Performance Insights enabled, you can use the Performance Insights dashboard to visualize the database load and filter the load by waits, SQL statements, hosts, or users.

After a test period (probably a couple of days or based on your comfort level), you can change the rest of the reader instances to Graviton2 and delete the snapshot created before the change.

Rollback

With any change, it’s important to have a fallback strategy if the new changes don’t work as expected. At a high level, you have a few options:

If your cluster has a x86 reader, you can fail over to a x86 instance in the cluster by changing the failover priority.
You also have the option of changing the instance type back to a x86 instance type following a similar process that we saw earlier in the post.
If you still see issues, you can restore from the snapshot that you took before you started the change. For more information about additional considerations when using either Amazon RDS or Aurora, see Restoring from a DB snapshot and Restoring from a DB cluster snapshot, respectively.

Rollback procedures are a separate topic in itself and outside the scope of this post.

Summary

This post provided step-by-step instructions to modify your Aurora PostgreSQL instances to Graviton2, along with some of the key considerations to minimize downtime. You can follow similar steps to modify RDS instances to Graviton2. We also briefly talked about the database upgrade process if you’re not at the minimum required version for Graviton2.

As a best practice, always test any changes on lower environments, including any database extensions that you may have, also make sure that your test environment resembles your production environment in terms of configuration and volume.

Additional resources

For more information and additional resources, see the following:

About the authors

Reagan Rosario works as a Solutions Architect focusing on EdTech at AWS. He loves helping customers build scalable, highly available, and secure solutions in the AWS Cloud.

Tyler Lynch is a Sr. Solutions Architect focusing on EdTech at AWS. He is passionate about education and lifelong learning.

AWS Database Blog