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 in 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 ACUs
||Scale up and down with a 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
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 an option to create Aurora Global database, all of which was not possible with Aurora Serverless V1. Another advantage of the newer version is the 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, 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 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 an 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.
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 modifying DB instance to Serverless v2 should take around 60-70 mins.
Blue/Green deployment to minimize risk and downtime
Utilising Blue/Green deployments for your managed databases means that a staging copy of your production environment will be created, that later on can be promoted to production. The 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, or 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 parameter 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 necessary upgrades on your new Green(staging) environment
Blue/Green deployments aren’t supported for Aurora Serverless v1, however it is available for Aurora provisioned with MySQL Compatibility 5.6 or higher, Amazon RDS for MariaDB 10.2 and higher and Serverless v2. More information about this is available here.