Best practices for upgrading Amazon RDS for MySQL 8.0 to 8.4 with prechecks, Blue/Green, and rollback

Upgrading a production MySQL database across major versions is one of the most high-stakes operations a database team faces. Compatibility breaks, unexpected downtime, and the risk of no easy rollback can stall upgrade plans for months. Amazon Relational Database Service (Amazon RDS) for MySQL 8.0 standard support ends on July 31, 2026, and Amazon RDS for MySQL now supports long-term support (LTS) version 8.4. Teams running MySQL 8.0 workloads need a reliable, low-risk path to MySQL 8.4. However, upgrading from 8.0 to 8.4 involves significant compatibility changes that you must evaluate and test before proceeding. In this post, you learn how to build a complete upgrade workflow for RDS for MySQL 8.0 to 8.4, covering pre-upgrade compatibility checks, Amazon RDS Blue/Green Deployments for minimal downtime, and a rollback strategy for added protection.

If you need to stay on MySQL 8.0 beyond that date, check the latest updates on RDS Extended Support. For a detailed breakdown of Extended Support costs, see Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4. You can also consider Amazon Aurora MySQL-Compatible Edition, which provides its own release calendar and still supports MySQL 8.0 without having to use extended support at least until 30 April 2028.

Solution overview

This post is part of a two-part series on upgrading RDS for MySQL 8.0 to 8.4. Here, we focus on the step-by-step implementation, covering pre-upgrade compatibility checks, Blue/Green Deployments, and rollback preparation. For an overview of upgrade strategies, Extended Support costs, and key considerations, see Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4.

In this post, we walk you through a complete upgrade workflow covering three tightly coupled phases:

1. Pre-upgrade checks: Identify incompatibilities using the MySQL Shell upgrade checker utility and RDS built-in validation.
2. Blue/Green Deployments: Perform the upgrade with minimal downtime using Amazon RDS Blue/Green Deployments.
3. Rollback preparation: Set up reverse replication before switchover so you can roll back with confidence.

These phases are not independent: pre-check results determine whether the green environment can upgrade successfully, the binlog position from Blue/Green Deployments creation feeds into the rollback setup, and you need to make sure the rollback solution is ready before you switchover. The following architecture diagram illustrates the complete workflow, helping you understand how each phase interacts with the others.

Prerequisites

Blue/Green Deployments and RDS for MySQL 8.4 are available in all AWS Regions. Before you begin, make sure you have the following resources in place:

• An Amazon RDS for MySQL 8.0 instance with automatic backups enabled.
• An Amazon Elastic Compute Cloud (Amazon EC2) instance or bastion host in the same VPC for running MySQL Shell.
• A custom DB parameter group created for MySQL 8.4.
• An IAM user or role with at least the following permissions for Blue/Green Deployments:
  • Create Blue/Green Deployments
    • rds:CreateBlueGreenDeployment
    • rds:AddTagsToResource
    • rds:CreateDBInstanceReadReplica
  • Switchover Blue/Green Deployments
    • rds:SwitchoverBlueGreenDeployment
    • rds:ModifyDBInstance
    • rds:PromoteReadReplica
  • Delete Blue/Green Deployments
    • rds:DeleteBlueGreenDeployment
    • rds:DeleteDBInstance
• (For rollback) An AWS Database Migration Service (AWS DMS) replication instance, or network connectivity between the 8.4 and 8.0 instances for native replication. Make sure the security groups associated with both instances allow MySQL traffic on port 3306 between them. If using AWS DMS, see AWS DMS identity-based policy examples for IAM permission best practices.

Phase 1: Pre-upgrade checks

Before upgrading, use the MySQL Shell check-for-server-upgrade utility to identify incompatibilities. Because the utility performs intensive metadata scans across all databases, we recommend running it against a snapshot-restored instance rather than your production database to avoid impacting workload performance. If you are working in a dev/test environment, you can skip the snapshot restore and run the check directly.

To run the pre-upgrade check:

1. Restore a DB snapshot of your MySQL 8.0 production instance. This gives you an isolated copy to safely run the check without affecting production.
2. Connect to your Amazon EC2 bastion host (or any instance in the same VPC that has MySQL Shell installed). If MySQL Shell is not already installed, see Installing MySQL Shell.
3. The upgrade checker utility requires RELOAD, PROCESS, and SELECT privileges. Before running the check, make sure your user account has these privileges. You can use the RDS master user, or grant the required privileges with the following commands:

-- Verify the privileges
SHOW GRANTS FOR '<user-name>'@'%';
-- Grant required privileges
GRANT RELOAD, PROCESS, SELECT ON *.* TO '<user-name>'@'%';

4. Run the upgrade checker:

# Run the upgrade checker (replace values accordingly)
mysqlsh -- util check-for-server-upgrade \
  --user=<user-name> --host=<instance-endpoint> --port=3306 \
  --target-version=8.4.x

The utility categorizes findings into three severity levels:

• Error (blocks upgrade).
• Warning (evaluate case-by-case).
• Notice (informational).

Whether an RDS for MySQL instance can successfully upgrade from 8.0 to 8.4 is ultimately determined by the RDS pre-upgrade validation. Therefore, this section focuses on the intersection of MySQL Shell’s check-for-server-upgrade findings and the RDS built-in pre-upgrade checks, providing a practical reference for planning your upgrade (detailed in the following section).

MySQL Shell vs. RDS pre-upgrade checks

The MySQL Shell upgrade checker and the RDS built-in pre-upgrade validation have slightly different default check items. The following table provides the main differences between the two. For detailed explanations and resolution steps for each check item, please see the “Understanding and resolving pre-upgrade check errors” section.

Items with a Source of Shell Only are not enforced by the RDS upgrade validation, so their Severity is marked as -.

The RDS built-in pre-upgrade validation only runs when you initiate an actual upgrade. If the validation finds blocking issues at that point, the upgrade fails and you need to resolve them and reschedule another maintenance window. Running the MySQL Shell upgrade checker beforehand helps you identify and resolve these issues in advance.

The recommended approach:

1. Run the MySQL Shell upgrade checker to resolve the overlapping items. RDS manages shell-only items marked “can be ignored” internally.
2. Perform a test upgrade on a snapshot-restored instance to catch the RDS-only items via PrePatchCompatibility.log.

Understanding and resolving pre-upgrade check errors

To show you the pre-upgrade check process and the Error items that block upgrades, we reproduced several Error items on our test environment. In the following sections, we walk you through the actual precheck output and the suggested resolution for each item, so you can interpret and resolve precheck errors in practice.

Issues reported by ‘check table x for upgrade’ command

Runs CHECK TABLE … FOR UPGRADE against each tables. Depending on the scope of impact, the severity varies. The following are examples of both Error and Warning types.

Check for deprecated or removed plugin usage

Checks for errors in column definitions

Check for allowed values in system variables

Checks for partitions by key using columns with prefix key indexes

Use of AUTO_INCREMENT for DOUBLE and FLOAT data types

RDS checked for the use of non-inclusive language in SQL statements

memcached plugin needs to be uninstalled before upgrade

DB instance must have enough free disk space

Detect system objects created as tables in sys schema

Key compatibility changes in MySQL 8.4

The following changes most commonly affect RDS for MySQL upgrades:

mysql_native_password deprecation: MySQL 8.4 defaults to caching_sha2_password. Existing users with mysql_native_password continue to work after the upgrade, but newly created users will use caching_sha2_password. To change the default authentication plugin, modify the authentication_policy parameter in your DB parameter group. If you do not plan to keep using mysql_native_password, consider switching affected users to caching_sha2_password on your MySQL 8.0 instance and validating application connectivity before proceeding with the upgrade.

Applications using older client drivers that do not support caching_sha2_password will fail to connect with the error: Authentication plugin ‘caching_sha2_password’ cannot be loaded. The following minimum driver versions are required:

Query affected users:

SELECT user, host, plugin FROM mysql.user
WHERE plugin = 'mysql_native_password';

restrict_fk_on_non_standard_key: New parameter in MySQL 8.4 (default ON) that blocks CREATE TABLE and ALTER TABLE statements from creating foreign keys on non-unique or partial keys. This does not affect existing foreign keys or the upgrade itself. It only applies to data definition language (DDL) operations after the upgrade. If your application creates or modifies foreign keys at runtime, set this parameter to OFF in your MySQL 8.4 parameter group, or adjust your DDL statements accordingly.

memcached plugin removal: If enabled in your option group, disable it before upgrading (the RDS pre-upgrade validation can also flag this as an Error).

Parameter default value changes in MySQL 8.4

Beyond the compatibility changes above, MySQL 8.4 also changes the default values for several system variables. If you have explicitly set some of these in your MySQL 8.0 parameter group, verify whether your values need to carry over to the MySQL 8.4 parameter group. If you are using the engine defaults, be aware of the new behavior. The following table only includes parameters that are modifiable in the RDS for MySQL 8.4 parameter group.

You can check which parameters have been explicitly modified in your current parameter group:

aws rds describe-db-parameters \
--db-parameter-group-name <your-parameter-group> \
--query "Parameters[?Source=='user'].[ParameterName,ParameterValue,Source]" \
--output table

For the complete list of changes, see Amazon RDS for MySQL LTS version 8.4 is now generally available.

Go/no-go checklist

Before proceeding to Phase 2, confirm:

• Error items from the upgrade checker are resolved.
• Warning items are evaluated and addressed or accepted.
• MySQL 8.4 parameter group is configured with necessary adjustments.
• Application driver compatibility with caching_sha2_password is verified.

Phase 2: Blue/Green Deployments (minimize downtime)

Amazon RDS Blue/Green Deployments lets you upgrade the major engine version, without affecting production. When you’re ready, you promote the staging environment to become the new production database with downtime typically five seconds or lower for single-Region configurations. This makes Blue/Green Deployments a practical choice for major version upgrades with minimal disruption. The following sections walk you through creating Blue/Green Deployments, upgrading the green environment to MySQL 8.4, and performing the switchover.

Prechecks

Before creating the deployment, confirm:

• Automatic backups are enabled.
• The instance is not an external binlog replica (SHOW REPLICA STATUS\G returns empty).
• No cascading read replicas exist (read replicas cannot have their own replicas). If cascading replicas exist, disconnect them before proceeding and re-create them after the upgrade is complete.
• Parameter group status shows In Sync.
• Binlog retention hours is set to at least 24 hours. This ensures enough binlog data remains after switchover for reverse replication. If the binlog is purged before reverse replication is configured, the rollback path cannot be established. Adjust the retention period based on your requirements.

CALL mysql.rds_set_configuration('binlog retention hours', 24);
CALL mysql.rds_show_configuration;

• Review the full list of Blue/Green Deployments limitations including unsupported features (AWS Secrets Manager managed passwords, Zero-ETL, cross-Region read replicas). If your instance uses any of these features, remove or disable them before creating the Blue/Green Deployments and re-enable them after upgrade.

Create and upgrade the green environment

1. Create the Blue/Green Deployments: Select the same engine version as the source instance initially. This avoids a failed automatic upgrade requiring you to rebuild the entire deployment.

2. After creation completes, manually upgrade the green instance to MySQL 8.4.x. Select your pre-configured MySQL 8.4 parameter group, or the default parameter group if you’re not customizing any parameters.

3. If the upgrade fails, check the green instance’s PrePatchCompatibility.log and Recent events for details. Resolve the issues and retry.
4. (Optional) If you plan to set up a rollback path in Phase 3, verify that binlog retention on the green instance (MySQL 8.4) is set to at least 24 hours before switchover. Otherwise, binlog files might be purged after switchover, making reverse replication impossible.

Switchover

Before switching over:

• Confirm ReplicaLag on the green instance is near zero.
• Check for long-running queries on the blue instance (SHOW PROCESSLIST).
• Verify both environments show Available status.
• Verify that the application isn’t caching DNS, or if it is then the cache TTL is 5 seconds or less.
• Complete the rollback setup in Phase 3 first

Set the switchover timeout to your acceptable downtime window (maximum 60 minutes). During switchover, existing connections are dropped.

After a successful switchover, RDS renames the old instance with a -old1 suffix and sets it to read-only. The new MySQL 8.4 instance takes the original name and endpoint. RDS automatically disconnects replication at this point. Blue/Green Deployments is a one-time operation. You can delete the Blue/Green Deployments at your convenience; doing so does not delete the old instance. If you do not need a rollback path, the upgrade is complete at this point.

Important: Note the binlog position recorded after switchover completed, you will need it for the rollback setup in Phase 3. Following these steps to find the binlog position after switchover:

1. Open the Amazon RDS console and select your new MySQL 8.4 instance.
2. Open the Logs & events tab and search for Binary log. Note the last recorded binlog file name and position. For example, in our test environment, the values are mysql-bin-changelog.000129 and position 1116.

Phase 3: Rollback preparation

Set up reverse replication from the new MySQL 8.4 instance to the old MySQL 8.0 instance after switchover, so you have a working rollback path if issues arise post-upgrade. This approach uses change data capture (CDC) to synchronize only incremental changes. The key input is the binlog position recorded in the switchover event (Logs & events → Recent events on the new MySQL 8.4 instance). Use this position to establish reverse replication back to the old 8.0 instance.

The following table provides a brief comparison between Option A (native replication) and Option B (AWS DMS) to help you choose the approach that best fits your environment:

Option A: Native replication (preferred)

Migration between RDS for MySQL instances is a homogeneous data migration. We recommend native replication as the preferred approach, because native database migration tools generally provide better performance and accuracy compared to AWS DMS.

After switchover, you do not need to change the read_only parameter to 0 on the MySQL 8.0 -old1 instance. In replication setups, it can be useful to enable read_only on replica servers to make sure that replicas accept updates only from the source server and not from clients.

1. Retrieve the binlog position from the new MySQL 8.4 instance (Logs & events → Recent events).
2. On the MySQL 8.4 instance, create a replication user.

-- The password below is for demonstration purposes only.
-- Please replace it with a strong password for actual use.
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user';

3. On the MySQL 8.0 -old1 instance, configure replication using the binlog position from step 1:

CALL mysql.rds_set_external_master('<mysql-8.4-endpoint>',
3306,
'repl_user',
'password',
'<binlog-file>',
<binlog-position>,
1 );
CALL mysql.rds_start_replication;

4. Verify with SHOW REPLICA STATUS\G and confirm the following:
   • Replica_IO_Running: Yes
   • Replica_SQL_Running: Yes
   • Seconds_Behind_Master is decreasing, approaching 0, and is not -1 or NULL

Option B: AWS DMS

If native replication is not suitable for your environment, you can use AWS DMS as an alternative to set up the rollback path.

Because the MySQL 8.0 -old instance is set to read-only after switchover, change the read_only parameter to 0 in its parameter group before creating the task.

• Step 1: Create a DMS replication instance
  • Instance class & Allocated storage: based on workload
  • Engine version: use the default
  • Virtual private cloud (VPC): use the same VPC as both the MySQL 8.4 (source) and MySQL 8.0 (target) instances. Note: If the source and target instances are in different VPCs, you need to configure VPC peering or another network connectivity option before creating the replication instance.
• Step 2: Create DMS endpoints
  • Source endpoint: use the MySQL 8.4 instance endpoint (after switchover)
  • Target endpoint: use the old MySQL 8.0 -old1 instance endpoint
  • Test both endpoint connections from the replication instance before proceeding
• Step 3: Create a CDC-only DMS task
  • Migration type: CDC only (ongoing replication)
  • CDC start position: enter the binlog position from the switchover event (Logs & events → Recent events on the new MySQL 8.4 instance)
  • Include LOB columns in replication: if your tables contain LOB columns, consider using Limited LOB mode for faster replication. This mode truncates LOB value that exceeds the configured Maximum LOB size, so you need to set it appropriately.
  • Maximum LOB size (KB): query the maximum LOB size in your instance first, then set accordingly:

SELECT MAX(LENGTH(<lob_column>)) / 1024 AS size_kb FROM <table_name>;

• Table mappings: either explicitly include the databases you want to synchronize, or use % to include every database and exclude system databases (mysql, sys, information_schema, performance_schema).
• Step 4: Monitor the task
  • Once the task status shows Replication ongoing, CDC synchronization is active and the rollback path is ready.

Once you have validated that the new RDS for MySQL 8.4 environment is working as expected, you can stop the DMS replication task and delete the old RDS for MySQL 8.0 instance.

Clean up

After completing the upgrade and confirming your application is running normally on MySQL 8.4, you should remove the resources created during this process to avoid incurring additional charges. Follow these steps in the AWS Management Console or the AWS Command Line Interface (AWS CLI):

• Deleting Blue/Green Deployments (deleting the deployment does not delete the DB instances).
  1. Open the Amazon RDS console and choose Databases.
  2. Select the Blue/Green Deployment → Choose Actions → ‘Delete’.

  aws rds delete-blue-green-deployment \
  --blue-green-deployment-identifier <deployment resource ID> \
  --no-delete-target

• Snapshot-restored RDS instance used for pre-upgrade checks.
• The old RDS for MySQL 8.0 -old1 instance (after you confirm rollback is no longer needed). For more AWS CLI options, see Deleting a DB instance.
  1. Open the Amazon RDS console and choose Databases.
  2. Select the instance → Choose ‘Actions’ → ‘Delete’.

  aws rds delete-db-instance \
  --db-instance-identifier <instance-identifier> \
  --final-db-snapshot-identifier <final db instance snapshot identifier> \
  --no-delete-automated-backups

• Amazon EC2 instance used for running prechecks (if applicable). For more AWS CLI options, see Terminate Amazon EC2 instances.
  1. Open the Amazon EC2 console and choose Instances.
  2. Select the EC2 instance used for running prechecks → Choose ‘Instance state’ → ‘Terminate (delete) instance’.

  aws ec2 terminate-instances \
  --instance-ids <instance-id>

• AWS DMS replication instance, endpoints, and task (if you used Option B for rollback).
  • Tasks:
    1. Open the AWS DMS console and choose Tasks.
    2. Select the DMS task used for rollback.
    3. If the task is still running, choose ‘Actions’ → ‘Stop’.

       aws dms stop-replication-task \
       --replication-task-arn <task-arn>

    4. After the task has stopped, choose ‘Actions’ → ‘Delete’.

       aws dms delete-replication-task \
       --replication-task-arn <task-arn>

  • Endpoints:
    1. Choose Endpoints.
    2. Select the source and target endpoints → Choose ‘Actions’ → ‘Delete’.

       aws dms delete-endpoint \
       --endpoint-arn <endpoint-arn>

  • Deleting a replication instance:
    1. Choose Provisioned instances.
    2. Select the replication instance → Choose ‘Actions’ → ‘Delete’.

       aws dms delete-replication-instance \
       --replication-instance-arn <instance-arn>

Conclusion

In this post, we walked through a three-phase approach for upgrading Amazon RDS for MySQL 8.0 to 8.4: interpreting pre-upgrade compatibility checks, performing the upgrade with minimal downtime using Amazon RDS Blue/Green Deployments, and setting up a rollback path with reverse replication. These phases give you a tested, reversible upgrade path with minimal downtime, reducing the risk that typically stalls major version upgrades. With MySQL 8.0 standard support ending on July 31, 2026, we encourage you to start planning your upgrade and validating your workloads against MySQL 8.4’s new features and performance improvements. If you need to continue using MySQL 8.0 beyond the standard support end date, see the breakdown of Extended Support costs in Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4.

To learn more, see Upgrading a MySQL DB instance engine version and Using Amazon RDS Blue/Green Deployments. If you have questions or feedback, leave a comment on this post.

About the authors