AWS Database Blog

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

HAQM RDS Multi-AZ deployments are ideal for production database workloads. When you have Multi-AZ deployment, HAQM Relational Database Service (HAQM RDS) provisions one primary and one standby DB instance with synchronous physical replication of HAQM Elastic Block Store (HAQM 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.

HAQM 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 HAQM 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 HAQM RDS for MySQL and HAQM RDS for PostgreSQL.

Solution overview

HAQM 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, HAQM RDS has offered Multi-AZ support since 2010.

HAQM RDS Multi-AZ deployments are ideal for production database workloads. When you provision a Multi-AZ DB instance, HAQM 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), HAQM 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, HAQM 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, HAQM 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.

HAQM RDS Multi-AZ deployments with readable standbys pair DB instances with local NVMe SSD storage and HAQM 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 HAQM RDS. The Multi-AZ deployments with readable standby instances are available on HAQM 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.

HAQM 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 HAQM RDS API.

HAQM 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 HAQM 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 HAQM RDS and your AWS solutions. To monitor your Multi-AZ DB cluster, you can take advantage of all the HAQM RDS monitoring tools, like HAQM CloudWatch, access to the database log files, HAQM RDS Enhanced Monitoring, HAQM RDS Performance Insights, HAQM RDS Recommendations, and HAQM RDS event notifications.

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

Summary

HAQM 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 HAQM 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 HAQM 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.