Amazon RDS Multi-AZ deployments provide enhanced availability and durability for RDS database (DB) instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure, Amazon RDS performs an automatic failover to the standby (or to a read replica in the case of Amazon Aurora), so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention.
Several Amazon RDS engines allow you to add read replicas for increased scalability and to maintain database availability in the case of an AZ failure. Amazon RDS read replicas can be set up with their own standby instances in a different AZ. In the case of Aurora, you can choose to place read replicas across multiple availability zones.
Amazon Aurora further extends the benefits of Multi-AZ by employing an SSD-backed virtualized storage layer purpose-built for database workloads. It automatically replicates your storage six ways, across three Availability Zones. Amazon Aurora storage is fault-tolerant, transparently handling the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Aurora always replicates your data across three Availability Zones, regardless of whether your database uses read replicas.
Benefits
Enhanced durability
Multi-AZ deployments for the MySQL, MariaDB, Oracle, and PostgreSQL engines utilize synchronous physical replication to keep data on the standby up-to-date with the primary. Multi-AZ deployments for the SQL Server engine use synchronous logical replication to achieve the same result, employing SQL Server-native Mirroring or Always-on technology. Amazon Aurora uses an SSD-backed virtualized storage layer purpose-built for database workloads. All approaches safeguard your data in the event of a DB Instance failure or loss of an Availability Zone.
Increased availability
You benefit from enhanced database availability when running Multi-AZ deployments. If an Availability Zone failure or DB Instance failure occurs, your availability impact is limited to the time automatic failover takes to complete: typically under one minute for Amazon Aurora (as little as 30 seconds when using the MariaDB Connector/J) and one to two minutes for other database engines.
The availability benefits of Multi-AZ deployments also extend to planned maintenance and backups. In the case of system upgrades like OS patching or DB Instance scaling, these operations are applied first on the standby, prior to the automatic failover. As a result, your availability impact is, again, only the time required for automatic failover to complete.
Protection of your database performance
Unlike Single-AZ deployments, I/O activity is not suspended on your primary during backup for Multi-AZ deployments for the MySQL, MariaDB, Oracle, and PostgreSQL engines, because the backup is taken from the standby. However, note that you may still experience elevated latencies for a few minutes during backups for Multi-AZ deployments.
On instance failure in Amazon Aurora deployments, Amazon RDS uses RDS Multi-AZ technology to automate failover to one of up to 15 Amazon Aurora Replicas you have created in any of three Availability Zones. If no Amazon Aurora Replicas have been provisioned, in the case of a failure, Amazon RDS will attempt to create a new Amazon Aurora DB instance for you automatically.
Automatic failover
If a storage volume on your primary instance fails in a Multi-AZ deployment, Amazon RDS automatically initiates a failover to the up-to-date standby (or to a replica in the case of Amazon Aurora). Compare this to a Single-AZ deployment: in case of a Single-AZ database failure, a user-initiated point-in-time-restore operation will be required. This operation can take several hours to complete, and any data updates that occurred after the latest restorable time (typically within the last five minutes) will not be available.
DB Instance failover is fully automatic and requires no administrative intervention. Amazon RDS monitors the health of your primary and standbys, and initiates a failover automatically in response to a variety of failure conditions.
Failover conditions
Amazon 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. Amazon RDS automatically performs a failover in the event of any of the following:
- Loss of availability in primary Availability Zone
- Loss of network connectivity to primary
- Compute unit failure on primary
- Storage failure on primary
Note: When operations such as DB Instance scaling or system upgrades like OS patching are initiated for Multi-AZ deployments, for enhanced availability, they are applied first on the standby prior to an automatic failover (see the Aurora documentation for details on update behavior). As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.
Setup
Using the Amazon Web Services Management Console, you can easily 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 Amazon Web Services Management Console, simply click the "Yes" option for "Multi-AZ Deployment" when launching a DB Instance. To convert an existing Single-AZ DB Instance to a Multi-AZ deployment, use the "Modify" option corresponding to your DB Instance in the Amazon Web Services Management Console.
Multi-AZ deployments, multi-region deployments, and read replicas
Amazon RDS Multi-AZ deployments complement multi-region deployments and read replicas. While all three features increase availability and durability by maintaining additional copies of your data, there are differences between them:
Multi-AZ deployments |
Multi-Region deployments |
Read replicas |
Main purpose is high availability |
Main purpose is disaster recovery and local performance |
Main purpose is scalability
|
Non-Aurora: synchronous replication; Aurora: asynchronous replication |
Asynchronous replication |
Asynchronous replication |
Non-Aurora: only the primary instance is active; Aurora: all instances are active |
All regions are accessible and can be used for reads |
All read replicas are accessible and can be used for readscaling |
Non-Aurora: automated backups are taken from standby; Aurora: automated backups are taken from shared storage layer |
Automated backups can be taken in each region |
No backups configured by default |
Always span at least two Availability Zones within a single region |
Each region can have a Multi-AZ deployment |
Can be within an Availability Zone, Cross-AZ, or Cross-Region |
Non-Aurora: database engine version upgrades happen on primary; Aurora: all instances are updated together |
Non-Aurora: database engine version upgrade is independent in each region; Aurora: all instances are updated together |
Non-Aurora: database engine version upgrade is independent from source instance; Aurora: all instances are updated together |
Automatic failover to standby (non-Aurora) or read replica (Aurora) when a problem is detected |
Aurora allows promotion of a secondary region to be the master |
Can be manually promoted to a standalone database instance (non-Aurora) or to be the primary instance (Aurora)
|
You can combine Multi-AZ deployments with other Amazon RDS features to enjoy the benefits of each. For example, you can configure a source database as Multi-AZ for high availability and create a read replica (in Single-AZ) for read scalability.
With RDS for MySQL, MariaDB, PostgreSQL, and Oracle, you can also set the read replica as Multi-AZ, allowing you to use the read replica as a DR target. When you promote the read replica to be a standalone database, it will already be Multi-AZ enabled.