Aurora Serverless V1 to V2 Migration
Tags: aws, aurora, database
Published: 2023-02-26 19:31:49

---
title: Aurora Serverless V1 to V2 Migration
published: true
description: The not-so-serverless database upgrade path for Aurora Serverless
tags: AWS,Aurora,Databases
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/twf9xplcvbpeqf3ssaeq.png
# Use a ratio of 100:42 for best results.
# published_at: 2023-02-26 19:23 +0000
canonical_url: https://rhuaridh.co.uk/blog/aurora-serverless-upgrade.html
---


## Introduction

So you have been enjoying running your MySQL 5.7 compatible database in Aurora Serverless V1. It's serverless, so by definition you don't need to worry about servers. Right?

Well that story rings true right up until you want to upgrade your Aurora Serverless database to be compatible with MySQL 8.0, then you might notice the checkbox is mysteriously missing for 8.0.

Let me take you on a **not-so-serverless** upgrade journey!

## Upgrade Map

First, take a look at my upgrade map:

![Aurora Serverless V1 to V2 Upgrade](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/twf9xplcvbpeqf3ssaeq.png)

That's right, in order to upgrade a **serverless** database we need to **provision** no fewer than 2 servers before making the switch back to **serverless**.

##### Related Links

From the official docs, here are some helpful links from AWS:

 * [Upgrading from an Aurora Serverless v1 cluster to Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html#aurora-serverless-v2.upgrade-from-serverless-v1-procedure)
 * [Converting a provisioned writer or reader to Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#aurora-serverless-v2-converting-from-provisioned)

### Step 1) Switch to Provisioned

First up, always take a snapshot. Who knows where this winding upgrade path will lead, so having a backup point is vital. 

The snapshot can then be restored as a new **provisioned** cluster.

### Step 2) Upgrade to MySQL 8.0

Provisioned clusters support both 5.7 and 8.0 compatible databases. So we can now modify the instance and select a version compatible with MySQL 8.0.

##### Why can't I upgrade from 5.7 to 8.0?

If you can see 8.0 as an option then skip this step. If not then read on!

Different minor version have different "_valid_" upgrades. While I'm not sure why AWS don't allow certain minor versions to upgrade to 8.0, what I do know is that you can use the following CLI calls to check.

For example, at the time of writing this `5.7.mysql_aurora.2.08.3` doesn't support an `8.0` upgrade. You can see this by running the following command and substituting your `--engine-version`.

```bash
aws rds describe-db-engine-versions --engine aurora-mysql \ 
  --engine-version 5.7.mysql_aurora.2.08.3 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[]
```

But if we perform a minor upgrade to `5.7.mysql_aurora.2.09.2` first then we can upgrade to an `8.0` version.

```bash
aws rds describe-db-engine-versions --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.09.2 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[
    "5.7.mysql_aurora.2.09.3",
    "5.7.mysql_aurora.2.10.0",
    "5.7.mysql_aurora.2.10.1",
    "5.7.mysql_aurora.2.10.2",
    "5.7.mysql_aurora.2.10.3",
    "5.7.mysql_aurora.2.11.0",
    "8.0.mysql_aurora.3.01.1",
    "8.0.mysql_aurora.3.02.0",
    "8.0.mysql_aurora.3.02.2"
]
```

### Step 3) Switch to Serverless V2

Now that your provisioned cluster supports MySQL 8.0 you can finally select the [upgrade the writer instance](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#aurora-serverless-v2-converting-from-provisioned) to be **Serverless V2**!



It only took 3+ database upgrades to perform one MySQL version jump.

## Conclusion

Honestly, consider just spinning up a new V2 cluster and using `mysqldump` instead. This upgrade path is far too convoluted!

The only occasion where I would recommend this over the old-fashioned `mysqldump` approach is if your database sizes are too large to be quickly exported/imported.