In this blog we will go through main differences between Aurora Serverless v1 and v2, how to upgrade your Aurora Serverless v1 cluster to v2 and how utilising blue/green deployment could help mitigate risk and downtime during future upgrades.
Aurora serverless v1 vs v2
Aurora Serverless v2 has become generally available in April 2022, with a promise of "90% cost savings compared to provisioning for peak capacity". Let's have a look at the main differences here:
| Aurora Serverless v1 | Aurora Serverless v2 |
|---|---|
| - scales only by increasing or decreasing the capacity of the writer | can scale both by changing the size of the DB instance and by adding more DB instances to the cluster, or by adding more regions to Aurora Global database |
| - all the compute for the cluster runs un a single AZ and region | - Multi AZ the same as in Aurora provisioned |
| - scaling cannot happen when SQL statements are running | -scaling can happen at any time (no requirement for quiet time |
| - scales up and down by doubling and halving ACU's | - Scale up and down with minimum increment of 0.5 ACUs |
| - reader DB instances aren't available, therefore cannot scale. | -reader DB can scales up and down independently of the writer |
| - best effort failover only, subject to capacity availability | -failover the same as is provisioned Aurora |
| - | - multi AZ -scaling based on memory -Aurora global databases - exporting snapshots to s3 - associating IAM role -RDS proxy - performance insights |
To summarise, upgrading to Aurora Serverless v2 would offer you more granularity with having the ability to scale down to 0.5 in comparison to 1 or 2 with v1. It also offers the same failover as provisioned clusters with multi AZ capability and and option to create Aurora Global database, all of which was not possible with Aurora Serverless V1. Another advantage of the newer version is ability to use RDS proxy.
These are just selected differences, however you can find the full list in AWS documentation.
Upgrading Aurora Serverless v1 to v2
For this demo purposes I will be using Aurora Serverless 2.07.01 MySQL 5.7–compatible and I will provide an approximate time each step should take.
- Create a DB cluster snapshot of the Aurora Serverless v1 cluster (around 2-4 mins)
- Restore the snapshot to create a new, provisioned (not Aurora Serverless) DB cluster running Aurora MySQL version 2. Choose the latest minor engine version available for the new cluster, which at the time of writing this is 2.11.0 (around 10 minutes)
It should take around 10-15 minutes for the new provisioned cluster to become available.
- When Cluster becomes available upgrade the provisioned Aurora MySQL version 2 cluster to a Aurora MySQL version 3 that s compatible with Aurora Serverless v2, i.e. 3.02.2. Here you can check Aurora Serverless v2 compatible versions.
(18-20 mins)
4.Modify the writer DB instance of the provisioned DB cluster to use the Serverless v2 DB instance class. (approx 20 mins).
Total approximate time for the upgrade from taking a snapshot to converting and modyfying DB instance to Serverless v2 should take around 60-70 mins.
Further documentation
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html#aurora-serverless-v2.upgrade-from-serverless-v1-procedure
Blue/Green deployment to minimize risk and downtime
Utilising Blue/Green deployments for you managed databeses means that a staging copy of your production enviroment will be created, that later on can be promoted to production. Staging environment stays in sync with your production database. All of this makes it possible for you to significantly decrease downtime when upgrading your database engine, changing schema or parameters. When you have thoroughly tested and undertaken any changes you wanted to your staging(green) copy, you can do a switchover and promote it to be a production(blue)environment, which usually takes less than a minute.
To create a Blue/Green deployment of your database cluster first you need to make sure that your database cluster is associated with a custom paramater group with binary logging turned on (binlog_format).
After associating your DB with a custom parameter group, you can now create Blue/Green deployment and perform any neccessary upgrades on your new Green(staging) environment
Blue/Green deployments aren't supported for Aurora Serverless v1, however it is available for Aurora provisioned a with MySQL Compatibility 5.6 or higher, Amazon RDS for MariaDB 10.2 and higher and Serverless v2. More information about this here
Top comments (1)
Hi, nice post :)
I have a question: when you restore the snapshot, why you restore it in a provisioned db Cluster and not directly in a Serverless v.2 cluster?
Thank you in advance
Francesco