AWS Database Blog

Best practices for converting a Single-AZ HAQM RDS instance to a Multi-AZ instance

Many database users spend a considerable amount of time architecting their database for high availability. High availability is critical for business continuity. With the AWS Cloud, you can create highly available databases using HAQM Relational Database Service (HAQM RDS).

HAQM RDS is a fully managed database service that makes it easy to set up, operate, and scale relational databases in the cloud. You can set up HAQM RDS in a Single-AZ database (DB) instance or a Multi-AZ DB instance for high availability requirements.

In this post, I discuss best practices for converting a Single-AZ DB instance to a Multi-AZ DB instance for HAQM RDS for MySQL, MariaDB, PostgreSQL, and Oracle databases, and how to reduce expected performance latencies from the conversion. HAQM RDS for SQL Server and HAQM Aurora use a different technology stack to provide Multi-AZ capabilities.

HAQM RDS architecture

Each HAQM RDS instance runs on a DB instance backed by an HAQM Elastic Block Store (HAQM EBS) volume for storage. HAQM RDS takes daily snapshots of the database, which are stored durably in HAQM Simple Storage Service (HAQM S3). In a Single-AZ setup, one RDS DB instance and one or more EBS storage volumes are deployed in one Availability Zone across data centers. In a Multi-AZ configuration, RDS DB instances and EBS storage volumes are deployed across multiple Availability Zones.

When you enable Multi-AZ, HAQM RDS maintains a redundant and consistent standby copy of your data using synchronous storage replication. HAQM RDS detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as quickly as possible without administrative intervention. HAQM RDS automatically performs a failover in the event of loss of availability in the primary Availability Zone, loss of network connectivity, compute unit failure, and storage failure, as described in HAQM RDS Multi-AZ Deployments. Having separate Availability Zones greatly reduces the likelihood that both copies are concurrently affected by most types of disturbances and therefore provides a highly available database architecture.

Convert Single-AZ to Multi-AZ

You can use the AWS Management Console, AWS Command Line Interface (AWS CLI), or HAQM RDS API to create new Multi-AZ deployments or modify existing Single-AZ instances to become Multi-AZ deployments. To create a new Multi-AZ deployment using the console, choose the Create a standby instance option for Multi-AZ deployment when launching a DB instance. To convert an existing Single-AZ DB instance to a Multi-AZ deployment, modify your DB instance via the console, AWS CLI, or HAQM RDS API. These changes are applied during the next maintenance window unless you choose to apply them immediately.

Why latency sometimes elevates during conversion

When converting a DB instance from Single-AZ to Multi-AZ, HAQM RDS creates a snapshot of the database volumes and restores these to new volumes in a different Availability Zone. Although the newly restored volumes are available almost immediately, they don’t reach their specified performance until the underlying storage blocks are copied from the snapshot.

Therefore, during the conversion from Single-AZ to Multi-AZ, you can experience elevated latency and performance impacts. This impact is a function of volume type, your workload, instance, and volume size, and can be significant and may impact large write-intensive DB instances during peak hour of operations. For more information, see Modifying a DB instance to be a Multi-AZ deployment.

How to minimize latency

To minimize these latencies and improve performance, you can use a read replica approach for HAQM RDS for MySQL, MariaDB, PostgreSQL, and Oracle Enterprise Edition databases ahead of time to prepare your environment. With this approach, underlying storage blocks are copied before they are accessed.

HAQM RDS Read Replicas make it easy to scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. You can create one or more replicas of a given source DB instance. In the following steps, I show how you can create a Multi-AZ read replica, synchronize it with your Single-AZ DB instance, and then promote it as your primary DB instance to minimize latencies during conversion.

  1. On the HAQM RDS console, select your database.
  2. On the Actions menu, choose Create read replica.
  3. Use your production DB instance as the source.
  4. Select Create a standby instance.

    For full instructions, see Creating a read replica.
  5. When the new read replica is synchronized, you can promote it to be the primary DB instance, and then redirect your application to the new primary.
    Plan your maintenance window for the cutover for a time after the new read replica is performing to expectations, by observing its HAQM CloudWatch write latency metric.
  6. When promoting the newly created read replica, you can rename both the source DB instance and the new read replica to maintain a consistent database endpoint.
  7. Enable automatic backups as needed.

Conclusion

This post showed you the best practices of converting a Single-AZ RDS DB instance to a Multi-AZ RDS DB instance for MySQL, MariaDB, PostgreSQL, and Oracle databases without compromising on performance. With the read replica approach, your upstream applications don’t experience elevated latencies and performance degradations during the data hydration period.

HAQM RDS Multi-AZ configurations improve the availability and durability of customer data. For more information, see HAQM RDS High Availability and High availability (Multi-AZ) for HAQM RDS.

If you have any questions or comments about this post, please share them in the comments.


About the author

Hanish Garg is a Senior Solutions Architect for the US State, Local Government, and Education team at HAQM Web Services. He’s passionate about helping customers achieve their business objectives with database and serverless technologies.