In a multi-AZ configuration, AWS will provision a standby MySQL instance in a separate AZ. Changes to your database will be replicated to the standby DB instance synchronously. If there is a problem with your primary DB instance, AWS will automatically fail over to the standby, promote it to be the primary DB, and provision a new standby.
You don't have access to query standby databases directly. So, you can't use it to handle all of your read queries, for example. If you wish to use additional database instances to increase read capacity, you'll need to provision a read replica. We'll cover those in a separate recipe.
Backups will always be taken from the standby instance, which means there is no interruption to your DB availability. This is not the case if you opted against deploying your DB in multi-AZ mode.
When you deploy this example, it will take roughly 20 minutes or more for the stack to report completion. This is because the RDS service needs to go through the following process to provide a fully working multi-AZ database:
- Provision the primary database.
- Back up the primary database.
- Provision the standby database using the backup from the primary.
- Configure both databases for synchronous replication.
Be careful about making changes to your RDS configuration after you've started writing data to it, especially when using CloudFormation updates. Some RDS configuration changes require the database to be re-provisioned, which can result in data loss. We'd recommend using CloudFormation changesets, which will allow you to see which changes are about to cause destructive behavior. The CloudFormation RDS documentation also provides some information on this.