Will a Multi-AZ deployment help reduce downtime during an Amazon RDS MySQL modification?
Last updated: 2021-07-09
I want to modify my Amazon Relational Database Service (Amazon RDS) for MySQL instance. Will a Multi-AZ deployment help reduce downtime?
When you modify your Amazon RDS MySQL instance, Multi-AZ deployments can reduce the impact of your changes.
Multi-AZ deployment can impact your Amazon RDS MySQL instance in the following scenarios:
- Modifying DB instance storage
- Updating the DB instance class
- Upgrading the DB engine version
- Maintaining the underlying OS or hardware
Note: Depending on the type of update that you're making, Multi-AZ deployments might not offer enhanced availability benefits.
Modifying DB instance storage
To modify Amazon RDS storage, the following storage modifications are available:
- Allocated storage size
- Provisioned IOPs value
- Storage type
Increasing the allocated storage size and changing the IOPs values are online operations that don't include downtime. Because these storage updates to both the primary and standby DB instance occur at the same time, Multi-AZ doesn't offer additional availability during storage updates. For more information about storage modifications and potential downtime, see Settings for DB instances.
There's also no downtime when you change the storage type of a Multi-AZ DB instance from General Purpose (SSD) to Provisioned IOPS (SSD), or vice versa. However, there is downtime in the following scenarios:
- From General Purpose (SSD) to Magnetic, or vice versa.
- From Provisioned IOPS (SSD) to Magnetic, or vice versa.
- From General Purpose (SSD) to Provisioned IOPS (SSD), but only if the DB instance is Single-AZ and you're using a custom parameter group.
- From Provisioned IOPS (SSD) to General Purpose (SSD), but only if the DB instance is Single-AZ and you're using a custom parameter group.
Updating the DB instance class
Because an instance class change requires a newly defined set of hardware, this change isn't an online operation, and therefore requires downtime. A Multi-AZ deployment of an Amazon RDS MySQL DB instance can significantly reduce any impact because the update doesn't happen simultaneously to the primary and standby. The standby instance is first modified, causing a failover. After the failover, the new standby is modified. The downtime required includes the duration of a failover completion (typically 60-120 seconds) and completion of the DB engine's crash recovery.
Upgrading the DB engine version
A DB engine version upgrade can be scheduled manually through the RDS console or API. Or, the DB engine upgrade occurs through an automatic minor version upgrade or after an engine deprecation. Because RDS MySQL doesn’t automate rolling upgrades, the DB engine version upgrade happens to both the primary and standby hosts at the same time. Therefore, a DB engine version upgrade doesn't benefit from a Multi-AZ deployment. To assess the scope and duration of impact, perform the upgrade in a staging environment before performing the actual upgrade. For more information, see Best practices for upgrading Amazon RDS for MySQL and Amazon RDS for MariaDB.
Note: If your RDS MySQL DB instance uses read replicas, you must upgrade all the read replicas before upgrading the source instance. For more information, see Using a read replica to reduce downtime when upgrading a MySQL database.
Performing a scheduled OS or hardware maintenance
When working with scheduled OS or hardware maintenance, Multi-AZ deployment can significantly reduce the impact of these changes.
Multi-AZ deployment impacts scheduled maintenance in the following ways:
- When maintenance is scheduled for only the primary host, a failover occurs and maintenance is performed on the new secondary host.
- When maintenance is scheduled for only the secondary host, there is no downtime.
- When maintenance is scheduled for both the primary and secondary hosts, maintenance is performed on the secondary (standby) host first. Then, a failover occurs, and maintenance is performed on the new secondary host.
For more information, see How do I minimize downtime during required RDS maintenance?