AWS Database Blog

Readable standby instances in Amazon RDS Multi-AZ deployments: A new high availability option

Amazon RDS Multi-AZ deployments are ideal for production database workloads. When you have Multi-AZ deployment, Amazon Relational Database Service (Amazon RDS) provisions one primary and one standby DB instance with synchronous physical replication of Amazon Elastic Block Store (Amazon EBS) storage for high availability and failover without data loss. However, you can’t read from the standby DB instance. If applications require more read capacity, you should create or add additional read replicas.

Amazon RDS now offers Multi-AZ deployments with readable standby instances (also called Multi-AZ DB cluster deployments) in preview. You should consider using Multi-AZ DB cluster deployments with two readable DB instances if you need additional read capacity in your Amazon RDS Multi-AZ deployment and if your application workload has strict transaction latency requirements such as single-digit milliseconds transactions.

This post describes Multi-AZ DB cluster deployment configurations for Amazon RDS for MySQL and Amazon RDS for PostgreSQL.

Solution overview

Amazon RDS makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while automating time-consuming administration tasks such as hardware provisioning, database setup, patching, and backups. This allows you to focus on your applications so you can give them the fast performance, high availability, security, and compatibility they need. Relational databases are at the heart of many types of applications. To allow you to build applications that are highly available typically in production environments, Amazon RDS has offered Multi-AZ support since 2010.

Amazon RDS Multi-AZ deployments are ideal for production database workloads. When you provision a Multi-AZ DB instance, Amazon RDS synchronously replicates your data to a standby instance in a different Availability Zone. Each Availability Zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby, so that your applications can resume database operations as soon as the failover is complete.

With the new topology of Multi-AZ cluster deployments, Amazon RDS supports database workloads that require more read capacity and consistent transaction latency, while providing high availability and durability. When you choose this new Multi-AZ DB deployment option, Amazon RDS provisions one primary and two readable standby DB instances across three Availability Zones and automatically configures data replication. The standby DB instances act as automatic failover targets and also serve read traffic, using either a reader endpoint or separate instance endpoints, to increase throughput without needing to attach additional read replica DB instances.

Amazon RDS Multi-AZ deployments with readable standbys pair DB instances with local NVMe SSD storage and Amazon EBS network storage to achieve transaction commit latency as low as single-digit milliseconds without compromising durability. The new Multi-AZ deployment option uses the database engine’s native replication in conjunction with AWS Gravtion2 R6gd or M6gd instance types to deliver high availability, performance, and throughput in a single deployment of Amazon RDS. The Multi-AZ deployments with readable standby instances are available on Amazon RDS for MySQL version 8.0.26 and PostgreSQL version 13.4.

Multi-AZ DB cluster architecture

A Multi-AZ DB cluster consists of one primary and two readable standby read replicas in three different Availability Zones. The primary (writer) DB instance serves read and write operations, and performs all the data modifications. The standby (reader) DB instances acts as a failover target for the primary and also serves read traffic. So, applications can offload read traffic from the primary DB instance to reader DB instances to increase application read throughput.

The following diagram illustrates this architecture.

Amazon RDS replicates data from the writer DB instance to both reader DB instances using the DB engine’s native replication capabilities. When a change is made on the writer DB instance, it’s sent to each reader DB instance. Acknowledgement from at least one reader DB instance is required for a change to be committed and applied.

Create a Multi-AZ DB cluster

You can create a Multi-AZ DB cluster using the AWS Management Console, AWS Command Line Interface (AWS CLI), or the Amazon RDS API.

Amazon RDS Multi-AZ deployments with readable standbys are currently available in preview in US East (N. Virginia), US West (Oregon), and EU (Ireland) Regions.

Before you create a Multi-AZ DB cluster, as a prerequisite, make sure your VPC has at least one subnet in each of the three Availability Zones in the Region where you want to deploy your DB cluster. This configuration ensures that your DB cluster always has at least two readable standby DB instances available for failover, in the unlikely event of an Availability Zone failure. For more information on working with DB instances in a VPC and DB subnet groups, check out Working with a DB instance in a VPC.

I want to call out two main configurations while you’re creating a Multi-AZ DB cluster via the console:

  • Make sure you choose the appropriate DB engine version. You can only create a Multi-AZ DB cluster with MySQL version 8.0.26 and PostgreSQL version 13.4.
  • Select Multi-AZ DB cluster in the Availability and durability section and acknowledge the limited-service agreement for this preview. For more information, visit Creating a Multi-AZ DB cluster.

To create a Multi-AZ DB cluster by using the AWS CLI, call the create-db-cluster command. Specify the --db-cluster-identifier. For the --engine option, specify either mysql or postgres.

The create-db-cluster command creates the writer DB instance for your DB cluster and two reader DB instances. Each DB instance is in a different Availability Zone. For example, the following command creates a PostgreSQL 13.4 Multi-AZ DB cluster named my-multi-az-db-cluster:

aws rds create-db-cluster \
   --db-cluster-identifier my-multi-az-db-cluster \
   --engine postgres \
   --engine-version 13.4  \
   --master-user-password password \
   --master-username postgres \
   --port 5432 \
   --backup-retention-period 1  \
   --db-subnet-group-name default \
   --allocated-storage 1000 \
   --storage-type io1 \
   --iops 10000 \
   --db-cluster-instance-class db.r6gd.xlarge

Connect to a Multi-AZ DB cluster

The host name and port that you specify point to an intermediate handler called an endpoint. The Multi-AZ DB cluster uses the endpoint mechanism to abstract these connections. So, when you connect to a Multi-AZ DB cluster, you don’t have to hardcode all the host names or write your own logic for load-balancing and rerouting connections when some DB instances aren’t available. Each Multi-AZ DB cluster has a cluster (read/write) endpoint, reader endpoint, and instance endpoint associated with each DB instance in a cluster.

Now let’s look at each endpoint that a Multi-AZ DB cluster provides:

  • Cluster endpoint – The cluster endpoint connects your application to the current primary DB instance for that Multi-AZ DB cluster. Your application can perform write operations such as DDL statements as well as read operations.
  • Reader endpoint – Each Multi-AZ DB cluster has a single built-in reader endpoint. You use the reader endpoint for read-only connections for your Multi-AZ DB cluster. The reader endpoint load balances connections across two readable standby DB instances to help your cluster handle a query-intensive workload. Consequently, it helps reduce load on your primary DB instance. However, it doesn’t load balance individual queries. If you want to load balance each query to distribute the read workload for a DB cluster, open a new connection to the reader endpoint for each query.
  • Instance endpoints – Each DB instance in a Multi-AZ DB cluster has its own unique instance endpoint, which you can use for diagnosis or tuning. You can connect to a specific instance endpoint to examine details about a specific DB instance, and a client application might require more fine-grained load balancing based on workload type. While connected to a specific DB instance, you can examine its status variables, metrics, and so on. Doing this can help you determine what’s happening for that DB instance that’s different from what’s happening for other DB instances in the cluster.

After Amazon RDS provisions your Multi-AZ DB cluster, you can use any standard SQL client application to connect to these endpoints. For more information, check out Connecting to a DB instance running the MySQL database engine and Connecting to a DB instance running the PostgreSQL database engine.

Monitor a Multi-AZ DB cluster

Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon RDS and your AWS solutions. To monitor your Multi-AZ DB cluster, you can take advantage of all the Amazon RDS monitoring tools, like Amazon CloudWatch, access to the database log files, Amazon RDS Enhanced Monitoring, Amazon RDS Performance Insights, Amazon RDS Recommendations, and Amazon RDS event notifications.

Amazon RDS provides additional metrics specific to Multi-AZ DB clusters in CloudWatch such as ReplicationLag, WriteIOPSLocalStorage, and WriteLatencyLocalStorage. For more information, visit Amazon RDS metrics.

Summary

Amazon RDS now provides a Multi-AZ DB cluster option, which is available in preview, to provide workloads that require more read capacity and consistent transaction latency, while providing high availability and durability. The Multi-AZ deployments with readable standby instances are available on Amazon RDS for MySQL version 8.0.26 and PostgreSQL version 13.4. You can easily create a Multi-AZ DB cluster using the console or AWS CLI in US East (N. Virginia), US West (Oregon), and EU (Ireland).

Have follow-up questions or feedback? Let us know by creating the technical support ticket or posting your question in the AWS forums, or leaving a comment here. I’d love to hear your thoughts and suggestions.

About the Author

Vijay Karumajji is a Database Solutions Architect with Amazon Web Services. He works with our customers to provide guidance and technical assistance on database projects, helping them improve the value of their solutions when using AWS.