Upgrading the minor version or patch level of an Aurora MySQL DB cluster - Amazon Aurora

Upgrading the minor version or patch level of an Aurora MySQL DB cluster

You can use the following methods to upgrade the minor version of a DB cluster or to patch a DB cluster:

For information about how zero-downtime patching can reduce interruptions during the upgrade process, see Using zero-downtime patching.

Before performing a minor version upgrade

We recommend that you perform the following actions to reduce the downtime during a minor version upgrade:

Minor version upgrade prechecks for Aurora MySQL

When you start a minor version upgrade, Amazon Aurora runs prechecks automatically.

These prechecks are mandatory. You can't choose to skip them. The prechecks provide the following benefits:

  • They enable you to avoid unplanned downtime during the upgrade.

  • If there are incompatibilities, Amazon Aurora prevents the upgrade and provides a log for you to learn about them. You can then use the log to prepare your database for the upgrade by reducing the incompatibilities. For detailed information about removing incompatibilities, see Preparing your installation for upgrade in the MySQL documentation.

The prechecks run before the DB instance is stopped for the upgrade, meaning that they don't cause any downtime when they run. If the prechecks find an incompatibility, Aurora automatically cancels the upgrade before the DB instance is stopped. Aurora also generates an event for the incompatibility. For more information about Amazon Aurora events, see Working with Amazon RDS event notification.

Aurora records detailed information about each incompatibility in the log file PrePatchCompatibility.log. In most cases, the log entry includes a link to the MySQL documentation for correcting the incompatibility. For more information about viewing log files, see Viewing and listing database log files.

Due to the nature of the prechecks, they analyze the objects in your database. This analysis results in resource consumption and increases the time for the upgrade to complete.

Upgrading Aurora MySQL by modifying the engine version

Upgrading the minor version of an Aurora MySQL DB cluster applies additional fixes and new features to an existing cluster.

This kind of upgrade applies to Aurora MySQL clusters where the original version and the upgraded version both have the same Aurora MySQL major version, either 2 or 3. The process is fast and straightforward because it doesn't involve any conversion for the Aurora MySQL metadata or reorganization of your table data.

You perform this kind of upgrade by modifying the engine version of the DB cluster using the AWS Management Console, AWS CLI, or the RDS API. For example, if your cluster is running Aurora MySQL 2.x, choose a higher 2.x version.

If you're performing a minor upgrade on an Aurora global database, upgrade all of the secondary clusters before you upgrade the primary cluster.


To perform a minor version upgrade to Aurora MySQL version 3.03.* or higher, or version 2.12.*, use the following process:

  1. Remove all secondary Regions from the global cluster. Follow the steps in Removing a cluster from an Amazon Aurora global database.

  2. Upgrade the engine version of the primary Region to version 3.03.* or higher, or version 2.12.*, as applicable. Follow the steps in To modify the engine version of a DB cluster.

  3. Add secondary Regions to the global cluster. Follow the steps in Adding an AWS Region to an Amazon Aurora global database.

To modify the engine version of a DB cluster

  • By using the console – Modify the properties of your cluster. In the Modify DB cluster window, change the Aurora MySQL engine version in the DB engine version box. If you aren't familiar with the general procedure for modifying a cluster, follow the instructions at Modifying the DB cluster by using the console, CLI, and API.

  • By using the AWS CLI – Call the modify-db-cluster AWS CLI command, and specify the name of your DB cluster for the --db-cluster-identifier option and the engine version for the --engine-version option.

    For example, to upgrade to Aurora MySQL version 2.12.1, set the --engine-version option to 5.7.mysql_aurora.2.12.1. Specify the --apply-immediately option to immediately update the engine version for your DB cluster.

  • By using the RDS API – Call the ModifyDBCluster API operation, and specify the name of your DB cluster for the DBClusterIdentifier parameter and the engine version for the EngineVersion parameter. Set the ApplyImmediately parameter to true to immediately update the engine version for your DB cluster.

Enabling automatic upgrades between minor Aurora MySQL versions

For an Amazon Aurora MySQL DB cluster, you can specify that Aurora upgrades the DB cluster automatically to new minor versions. You do so by setting the AutoMinorVersionUpgrade property (Auto minor version upgrade in the AWS Management Console) of the DB cluster.

Automatic upgrades occur during the maintenance window. If the individual DB instances in the DB cluster have different maintenance windows from the cluster maintenance window, then the cluster maintenance window takes precedence.

Automatic minor version upgrade doesn't apply to the following kinds of Aurora MySQL clusters:

  • Clusters that are part of an Aurora global database

  • Clusters that have cross-Region replicas

The outage duration varies depending on workload, cluster size, the amount of binary log data, and if Aurora can use the zero-downtime patching (ZDP) feature. Aurora restarts the database cluster, so you might experience a short period of unavailability before resuming use of your cluster. In particular, the amount of binary log data affects recovery time. The DB instance processes the binary log data during recovery. Thus, a high volume of binary log data increases recovery time.


Aurora only performs automatic upgrades if all DB instances in your DB cluster have the AutoMinorVersionUpgrade setting enabled. For information on how to set it, and how it works when applied at the cluster and instance levels, see Automatic minor version upgrades for Aurora DB clusters.

Then if an upgrade path exists for the DB cluster's instances to a minor DB engine version that has AutoUpgrade set to true, the upgrade will take place. The AutoUpgrade setting is dynamic, and is set by RDS.

Auto minor version upgrades are performed to the default minor version.

You can use a CLI command such as the following to check the status of the AutoMinorVersionUpgrade setting for all of the DB instances in your Aurora MySQL clusters.

aws rds describe-db-instances \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

That command produces output similar to the following:

[ { "DBInstanceIdentifier": "db-t2-medium-instance", "DBClusterIdentifier": "cluster-57-2020-06-03-6411", "AutoMinorVersionUpgrade": true }, { "DBInstanceIdentifier": "db-t2-small-original-size", "DBClusterIdentifier": "cluster-57-2020-06-03-6411", "AutoMinorVersionUpgrade": false }, { "DBInstanceIdentifier": "instance-2020-05-01-2332", "DBClusterIdentifier": "cluster-57-2020-05-01-4615", "AutoMinorVersionUpgrade": true }, ... output omitted ...

In this example, Enable auto minor version upgrade is turned off for the DB cluster cluster-57-2020-06-03-6411, because it's turned off for one of the DB instances in the cluster.

Using zero-downtime patching

Performing upgrades for Aurora MySQL DB clusters involves the possibility of an outage when the database is shut down and while it's being upgraded. By default, if you start the upgrade while the database is busy, you lose all the connections and transactions that the DB cluster is processing. If you wait until the database is idle to perform the upgrade, you might have to wait a long time.

The zero-downtime patching (ZDP) feature attempts, on a best-effort basis, to preserve client connections through an Aurora MySQL upgrade. If ZDP completes successfully, application sessions are preserved and the database engine restarts while the upgrade is in progress. The database engine restart can cause a drop in throughput lasting for a few seconds to approximately one minute.

ZDP doesn't apply to the following:

  • Operating system (OS) patches and upgrades

  • Major version upgrades

ZDP is available for all supported Aurora MySQL versions and DB instance classes.

ZDP isn't supported for Aurora Serverless v1 or Aurora global databases.


We recommend using the T DB instance classes only for development and test servers, or other non-production servers. For more details on the T instance classes, see Using T instance classes for development and testing.

You can see metrics of important attributes during ZDP in the MySQL error log. You can also see information about when Aurora MySQL uses ZDP or chooses not to use ZDP on the Events page in the AWS Management Console.

In Aurora MySQL version 2.10 and higher and version 3, Aurora can perform a zero-downtime patch whether or not binary log replication is enabled. If binary log replication is enabled, Aurora MySQL automatically drops the connection to the binlog target during a ZDP operation. Aurora MySQL automatically reconnects to the binlog target and resumes replication after the restart finishes.

ZDP also works in combination with the reboot enhancements in Aurora MySQL 2.10 and higher. Patching the writer DB instance automatically patches readers at the same time. After performing the patch, Aurora restores the connections on both the writer and reader DB instances. Before Aurora MySQL 2.10, ZDP applies only to the writer DB instance of a cluster.

ZDP might not complete successfully under the following conditions:

  • Long-running queries or transactions are in progress. If Aurora can perform ZDP in this case, any open transactions are canceled.

  • Temporary tables or table locks are in use, for example while data definition language (DDL) statements run. If Aurora can perform ZDP in this case, any open transactions are canceled.

  • Pending parameter changes exist.

If no suitable time window for performing ZDP becomes available because of one or more of these conditions, patching reverts to the standard behavior.


For Aurora MySQL version 2 lower than 2.11.0 and version 3 lower than 3.04.0, ZDP might not complete successfully when there are open Secure Socket Layer (SSL) or Transport Layer Security (TLS) connections.

Although connections remain intact following a successful ZDP operation, some variables and features are reinitialized. The following kinds of information aren't preserved through a restart caused by zero-downtime patching:

  • Global variables. Aurora restores session variables, but it doesn't restore global variables after the restart.

  • Status variables. In particular, the uptime value reported by the engine status is reset after a restart that uses the ZDR or ZDP mechanisms.


  • In-memory auto_increment state for tables. The in-memory auto-increment state is reinitialized. For more information about auto-increment values, see MySQL Reference Manual.

  • Diagnostic information from INFORMATION_SCHEMA and PERFORMANCE_SCHEMA tables. This diagnostic information also appears in the output of commands such as SHOW PROFILE and SHOW PROFILES.

The following activities related to zero-downtime restart are reported on the Events page:

  • Attempting to upgrade the database with zero downtime.

  • Attempting to upgrade the database with zero downtime finished. The event reports how long the process took. The event also reports how many connections were preserved during the restart and how many connections were dropped. You can consult the database error log to see more details about what happened during the restart.

Alternative blue/green upgrade technique

In some situations, your top priority is to perform an immediate switchover from the old cluster to an upgraded one. In such situations, you can use a multistep process that runs the old and new clusters side-by-side. Here, you replicate data from the old cluster to the new one until you are ready for the new cluster to take over. For details, see Using Amazon RDS Blue/Green Deployments for database updates.