AWS RDS Aurora Mysql Minor Version Upgrade Recommendation
Hi, just want to ask for some guide on how we should treat this recommendation that pops-up on our RDS aurora mysql cluster, I'm trying to read some documentation but still something is not clear to me and I'm just afraid to do it since it is a production server and we can't request a downtime yet.
When I saw this recommendation 3 days ago (May 16), I thought it will apply on the set maintenance period which was (May 17 - May 18), but It didn't. I read somewhere that I should modify the cluster > edit the engine version and set the latest version there > then apply on next maintenance windows for it to run automatically on the schedule maintenance, is that correct? Will it require a downtime during that maintenance period? Also what will happen if I apply it now? Will it also required a downtime or will just do the failover where the reader will be promoted as the new writer so that AWS can upgrade first the current writer instance then do upgrade next on the reader instance? Please avise.
- Newest
- Most votes
- Most comments
To address the Aurora MySQL minor version upgrade recommendation, you have a few options:
-
Automatic upgrades: You can enable automatic minor version upgrades by setting the AutoMinorVersionUpgrade property for your DB cluster. This will allow Aurora to automatically upgrade your cluster to new minor versions during the maintenance window.
-
Manual upgrade: You can manually initiate the upgrade by modifying the engine version of the DB cluster. This can be done through the AWS Management Console, AWS CLI, or RDS API. You're correct that you can modify the cluster, select the latest version, and apply it during the next maintenance window.
Regarding downtime:
- Minor version upgrades for Aurora MySQL are designed to be relatively fast and straightforward since they don't involve metadata conversion or data reorganization.
- The upgrade process includes prechecks to identify potential incompatibilities before the actual upgrade begins, which helps prevent unplanned downtime.
- During the upgrade, there will be a brief period of unavailability as the cluster switches over to the upgraded version. The duration depends on factors like workload, cluster size, and binary log data.
- If you're using a Multi-AZ configuration, the upgrade process will upgrade reader instances first, then promote one of them to be the new writer. This approach minimizes downtime to essentially just the failover period.
To minimize impact:
- Schedule the upgrade during a period of low traffic. You can use Performance Insights to identify suitable time windows.
- Use AWS SDKs that support exponential backoff and jitter to handle any temporary unavailability during the upgrade.
If you choose to apply the upgrade immediately, it will follow the same process as described above. The system will attempt to minimize downtime, but there will still be a brief period of unavailability during the switchover.
Given that this is a production server, it's advisable to:
- Thoroughly test the upgrade in a non-production environment first.
- Schedule the upgrade for a low-traffic period.
- Ensure you have recent backups before proceeding.
- Communicate the planned upgrade to relevant stakeholders.
Remember, while minor version upgrades are generally low-risk, it's always best to approach them cautiously in a production environment.
Sources
Upgrading the minor version or patch level of an Aurora MySQL DB cluster - Amazon Aurora
Enabling automatic upgrades between minor Aurora MySQL versions - Amazon Aurora
Upgrading Aurora MySQL by modifying the engine version - Amazon Aurora
Upgrading the engine version of a Multi-AZ DB cluster for Amazon RDS - Amazon Relational Database Service
answered a year ago
Relevant content
asked 7 months ago
asked 2 years ago
