Amazon RDS Multi-AZ deployments provide enhanced availability and durability for 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 (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby 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, you application can resume database operation without the need for manual administrative intervention.
Multi-AZ deployments utilize synchronous physical replication, keeping data on the standby up-to-date with the primary. This safeguards your data in the event of a DB Instance failure or loss of an Availability Zone. For example, if a storage volume on your primary fails, Amazon RDS automatically initiates a failover to the up-to-date standby for Multi-Az deployments. For Single-AZ deployments, in case of a database failure, a user-initiated point in time restore operation will be required. This operation can take several hours to complete and in addition any updates that occurred after the latest restorable time (typically within the last five minutes) will not be available.
You also 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 three to six minutes). The availability benefits of Multi-AZ deployments also extend to planned maintenance and backups. Unlike Single-AZ deployments, I/O activity is not suspended on your primary during backup for Multi-AZ deployments as 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. 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 limited only to the time required for automatic failover to complete.
DB Instance failover is fully automatic and requires no administrative intervention. Amazon RDS monitors the health of your primary and standby, and initiates a failover automatically in response to a variety of failure 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:
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. 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.
Please refer to Amazon RDS pricing page for more details.
Using the AWS 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 AWS 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 AWS Management Console.
Amazon RDS allows you to use MySQL’s built-in replication with Read Replicas, to scale beyond the capacity constraints of a single DB Instance for read-heavy database workloads. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them. You also have the option to promote a Read Replica as a standalone master for data recovery purposes should you so choose. However, unlike Multi-AZ deployments, Read Replicas use MySQL’s built-in replication and updates are applied to your Read Replica after they occur on the source DB Instance ("asynchronous" replication), and replication lag can vary significantly. This means recent database updates made to a DB Instance may not be present on associated Read Replicas in the event of an unexpected failure of the source DB Instance. As such, Read Replicas do not offer the same data durability benefits as Multi-AZ deployments.
You can use Multi-AZ deployments and Read Replicas in conjunction to enjoy the complementary benefits of each. You can simply specify that a given Multi-AZ deployment is the source DB Instance for your Read Replicas. That way you gain both the data durability and availability benefits of Multi-AZ deployments and the read scaling benefits of Read Replicas.
Note that for Multi-AZ deployments, you have the option to create your Read Replica in an AZ other than that of the primary and the standby for even more redundancy. You can identify the AZ corresponding to your standby by looking at the "Secondary Zone" field of your DB Instance in the AWS Management Console.