6. How do I set up a Multi-AZ DB instance deployment ?
In order to create a Multi-AZ DB instance deployment, simply click the “Yes” option for “Multi-AZ Deployment” when launching a DB Instance with the AWS Management Console. Alternatively, if you are using the Amazon RDS APIs, you would call the CreateDBInstance API and set the “Multi-AZ’ parameter to the value ‘true.’ To convert an existing standard (single AZ) DB instance to Multi-AZ, modify the DB instance in the AWS Management Console or use the ModifyDBInstance API and set the Multi-AZ parameter to true.
7. What are the benefits of a Multi-AZ deployment ?
The chief benefits of running your DB instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments. Running your DB instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB instance component failure or loss of availability in one Availability Zone.
8. What do primary and standby mean in the context of a Multi-AZ deployment ?
When you run a DB instance as a Multi-AZ deployment, the primary serves database writes and reads. In addition, Amazon RDS provisions and maintains a standby behind the scenes, which is an up-to-date replica of the primary. The standby is “promoted” in failover scenarios. After failover, the standby becomes the primary and accepts your database operations. You do not interact directly with the standby (e.g. for read operations) at any point prior to promotion.
9. Are there any performance implications of running my DB instance as a Multi-AZ deployment ?
YES . We observe elevated latencies relative to a standard DB instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf.
10. When running my DB instance as a Multi-AZ deployment, can I use the standby for read or write operations ?
No, a Multi-AZ standby cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. Our implementation makes sure the primary and the standby are constantly in sync, but precludes using the standby for read or write operations.