Book a call →
  1. Home
  2. Articles
  3. Guide

Guide

Upgrading to Aurora MySQL version 3

Aurora MySQL version 2 is past the end of standard support, and staying on it now costs extra. How to plan the move to version 3 (MySQL 8.0 compatible), find the incompatibilities before they block you, and cut over with little downtime.

  • By Anwar Alawad
  • Updated 1 October 2026
  • Read 7 min
01 · Why now

Why now

Aurora MySQL version 2, compatible with MySQL 5.7, reached the end of standard support on 31 October 2024. Clusters still on it were automatically enrolled in RDS Extended Support, a paid service that runs until February 2027. Every month on version 2 now costs more, and the deadline doesn’t move.

Anwar has migrated databases from MySQL to Amazon Aurora, and upgraded to Aurora MySQL version 3. This is the process in outline.

02 · Prechecks

Find the incompatibilities first

Aurora runs mandatory compatibility checks before a major upgrade. If any check reports an error, the upgrade is cancelled before the database goes offline, and the details are written to the upgrade-prechecks.log file. Find these issues on a copy, not on the day.

The most common problems:

  • New reserved words. Names such as tables, columns or routine variables that MySQL 8.0 now reserves must be quoted or renamed.
  • Removed syntax and features. For example SQL_CACHE and SQL_NO_CACHE in views and routines, and ASC or DESC on GROUP BY.
  • Zero dates. 0000-00-00 date, datetime and timestamp values.
  • Character sets. utf8 is an alias for the deprecated utf8mb3. Plan a move to utf8mb4.
  • Definers and names. Triggers and events with missing definers, and mixed-case names when lower_case_table_names is set.
03 · Method

Choosing an upgrade method

MethodDowntimeBest when
Blue/Green DeploymentA switchover, typically under a minuteProduction, where downtime matters. A green copy is upgraded and kept in sync, then swapped in.
In-place upgradeThe cluster is offline during the upgradeSmaller databases, or where a maintenance window is acceptable
Snapshot restore to a new clusterDepends on how you cut overTesting, or when you want a clean new cluster
04 · Plan

The plan, step by step

  1. Clone the cluster and upgrade the clone. The prechecks run against your real schema and data.
  2. Fix every error in upgrade-prechecks.log, and review the warnings and notices.
  3. Test the application against the upgraded clone, including stored procedures, reports and anything that uses unusual SQL.
  4. Check parameter groups. Version 3 needs its own cluster and instance parameter groups. Recreate any custom settings.
  5. Upgrade production with a Blue/Green Deployment, during a quiet period, with a rollback plan agreed in advance.
  6. Watch it after the switchover: slow queries, error rates and replication lag.

The prechecks themselves use CPU and memory, and can be slow on a cluster with many objects. Running them on a clone or the green environment keeps that load off production.

05 · Sources

Sources

See also AWS consulting.

Next step

Planning a database upgrade?

On a 30-minute call we’ll look at your cluster and the safest path to version 3.

Book a discovery call →