Explore

AWS RDS

Multi AZ deployments and Read Replicas

Multi-AZ DB instance deployments

Amazon RDS provides high availability and failover support for DB instances using Multi-AZ deployments with a single standby DB instance of your primary database instance in a different AZ. This type of deployment is called a Multi-AZ DB instance deployment.

Amazon RDS uses several different technologies to provide this failover support.

Multi-AZ deployments for MariaDB, MySQL, Oracle, PostgreSQL, and RDS Custom for SQL Server DB instances use the Amazon failover technology.

Microsoft SQL Server DB instances use SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs).

In a Multi-AZ DB instance deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy and minimize latency spikes during system backups. Running a DB instance with high availability can enhance availability during planned system maintenance. It can also help protect your databases against DB instance failure and Availability Zone disruption.

⁠

Note

The high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic. To serve read-only traffic, use a Multi-AZ DB cluster or a read replica instead. For more information about Multi-AZ DB clusters, see

Multi-AZ DB cluster deployments⁠

. For more information about read replicas, see

Working with DB instance read replicas⁠

DB instances using Multi-AZ DB instance deployments can have increased write and commit latency compared to a Single-AZ deployment. This can happen because of the synchronous data replication that occurs. You might have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. For production workloads, we recommend that you use Provisioned IOPS (input/output operations per second) for fast, consistent performance.

Key features and considerations include:

High Availability:

Multi-AZ deployments use synchronous replication to create a standby instance in a different AZ, providing enhanced disaster recovery (DR) capabilities.

Automatic Failover:

Failover occurs automatically in case of primary DB instance failure, AZ failure, loss of network connectivity, or storage failure.

Manual failover can be initiated by rebooting the instance and selecting the failover option.

Performance Considerations:

AWS recommends using provisioned IOPS storage for Multi-AZ DB instances to ensure consistent performance.

There is no charge for data transfer between primary and secondary instances.

Maintenance:

System upgrades, such as OS patching and instance scaling, are first applied to the standby instance, which is then promoted to primary, minimizing downtime.

Snapshots and automated backups are taken from the standby instance to avoid I/O suspension on the primary instance.

DB Instance Configuration:

During setup, you cannot choose the specific AZ for the standby instance, but you can view which AZ it is in after creation.

Applications should use the endpoint rather than IP addresses to connect to the RDS DB instance to handle failover seamlessly.

Limitations:

The standby DB in a Multi-AZ setup cannot be used as an independent read node.

Read Replica Support:

Multi-AZ deployments support read replicas, which can be in the same or different regions, providing additional redundancy and read scalability.

⁠

Multi-AZ DB cluster deployments

A Multi-AZ DB cluster deployment is a semisynchronous, high availability deployment mode of Amazon RDS with two readable replica DB instances. A Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate Availability Zones in the same AWS Region. Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower write latency when compared to Multi-AZ DB instance deployments. Feature availability and support varies across specific versions of each database engine, and across AWS Regions.

With a Multi-AZ DB cluster, Amazon RDS replicates data from the writer DB instance to both of the 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.

Multi-AZ DB cluster deployments use semi-synchronous replication, which requires acknowledgment from at least one reader DB instance in order for a change to be committed. It doesn't require acknowledgment that events have been fully executed and committed on all replicas.

Reader DB instances act as automatic failover targets and also serve read traffic to increase application read throughput. If an outage occurs on your writer DB instance, RDS manages failover to one of the reader DB instances. RDS does this based on which reader DB instance has the most recent change record.

The following diagram shows a Multi-AZ DB cluster:

⁠

Read Replicas

Read replicas in Amazon RDS provide read-only copies of your database for handling read-heavy workloads. They help in workload sharing and offloading.

⁠

Key features and considerations include:

Replication:

Read replicas use asynchronous replication from the primary DB instance.

Supported for MySQL, PostgreSQL, MariaDB, Oracle, Aurora, and SQL Server engines.

Scalability and Performance:

Read replicas can be used to scale out read-heavy applications.

Up to 5 read replicas can be created for a single DB instance.

Backup and Snapshots:

Automated backups must be enabled on the primary instance to create read replicas.

PostgreSQL read replicas can have snapshots taken but not automated backups.

MySQL and MariaDB read replicas can have automatic backups enabled.

Writable Replicas:

Writes can be enabled for MySQL and MariaDB read replicas.

Promoted read replicas inherit the backup retention window, backup window, and DB parameter group from the primary instance.

Cross-Region Replication:

Read replicas can be deployed in different regions to centralize data and provide regional redundancy.

Cross-region replication is asynchronous, which is suitable for disaster recovery and global data distribution.

Promotion to Primary:

Read replicas can be promoted to primary DB instances, which involves several minutes of downtime.

Promoted replicas retain existing configurations and read replicas continue to function as normal.

Management:

Read replicas must be explicitly deleted.

If the primary instance is deleted without deleting the replicas, each replica becomes a standalone single-AZ DB instance.

Configuration and Flexibility:

Read replicas can be configured from the AWS Console or API.

You can specify the AZ, storage type, and instance class for the read replica, provided it meets the performance criteria of the source instance.

Multi-AZ can be enabled for read replicas.

⁠

multi-az vs read replicas

multi-az vs read replicas

Column 1

Column 2

Multi-AZ Instance Deployments

Read Replicas

Synchronous Replication – highly durable

Asynchronous replication – highly scalable

Only database engine on primary instance is active

All read replicas are accessible and can be used for read scaling

Automated backups are taken from standby

No backups configured by default

Always span two availability zones within a single region

Can be within an Availability Zone, Cross-AZ, or Cross-Region

Database engine version upgrades happen on primary

Database engine version upgrade is independent from source instance

Automatic failover to standby when a problem is detected

Can be manually promoted to a standalone database instance

There are no rows in this table

⁠

Multi-AZ DB instance deployments

Multi-AZ DB cluster deployments

Read Replicas

multi-az vs read replicas

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.