What factors affect my downtime or database performance in Amazon RDS?
Last updated: 2021-06-09
I'm trying to modify my Amazon Relational Database Service (Amazon RDS) DB instance. What's the potential impact to database availability or performance during this change?
Modifying an instance class in Amazon RDS
When you modify the instance class of a Single-AZ instance in Amazon RDS, a new Amazon Elastic Compute Cloud (Amazon EC2) host is created. After the new Amazon EC2 host is created with the updated instance class, the existing host's database will be shut down. Data storage is then detached from the old host and reattached to the new host of a requested instance class. Your database is then restarted and the engine performs recovery to make sure that your database remains in a consistent state. Any outages during this process will be proportional to the duration of database recovery.
When you modify the instance class of a Multi-AZ instance in Amazon RDS, first your standby instance is updated. After this update, a failover occurs, switching roles of the standby and primary instances. The failover mechanism also propagates the DNS endpoint of the DB instance to point to the new host. After database recovery, the database can be accessed by the application. The instance class modification is then performed on the new standby instance.
Depending on your database activity or any long-running transactions, your failover might take longer than usual to complete. Failovers typically complete within 60–120 seconds. However, large transactions or a lengthy recovery process can increase failover time. It's a best practice to make sure that there are no open transactions in your database during an instance modification. You can also schedule a maintenance task to avoid any disruptions.
Modifying storage in Amazon RDS
If you need additional space for data or different storage performance attributes, Amazon RDS supports updates to the following (without performance impact):
- Storage allocation
- Volume type
Amazon RDS leverages Amazon Elastic Block Store (Amazon EBS) Elastic Volumes to minimize the time required for storage scaling operations. Based on the amount of storage requested, Amazon RDS automatically stripes across multiple Amazon EBS volumes to enhance performance.
When you modify your instance to add storage, your DB instance is fully operational for the application queries. After you modify storage on an RDS instance, there is a six-hour grace period before you can make additional storage updates. During this period, the instance status shows as “storage optimization”. When your instance enters the “storage optimization” phase, the new storage attributes are fully enabled, and performance isn't impacted.
Scaling storage in Amazon RDS
Scaling storage is an online process, and the database is fully operational during the process. However, for some legacy RDS instances, a one-time storage conversion is required.
During this operation, I/O performance might be impacted while Amazon RDS reads data from the old set of volumes and writes to the new set. Additionally, when scaling beyond 400 GB (or 200 GB for Oracle database instances), Amazon RDS also uses the legacy method for scaling. During the legacy method, you might experience performance degradation. All subsequent scaling storage modifications will use the elastic scaling method.
Single-AZ to Multi-AZ conversions in Amazon RDS
When you convert a DB instance from Single-AZ to Multi-AZ, Amazon RDS first creates a copy of the database. Then, the copy is restored in a different Availability Zone. Because restoring EBS snapshots is also part of this process, storage blocks will be copied over to the new volume. As a result, Single-AZ to Multi-AZ conversions can impact latency and DB instance performance. For more information, see High availability (Multi-AZ) for Amazon RDS.
The impact of converting to Multi-AZ is more pronounced for write-intensive DB instances with large storage volumes, during high workload periods. Additionally, any operation that involves restoring volumes (such as creating read replicas or restoring snapshots into a new DB instance) will result in increased latency. After the storage blocks are copied over from Amazon Simple Storage Service (Amazon S3) to the new volume, any latency will subside.