How to perform upgrades from MySQL 8.0 to 8.4 LTS on Tessell
Overview
MySQL 8.4 is a Long-Term Support (LTS) release that provides a stable, production-ready database platform with extended support duration. This major version upgrade from MySQL 8.0 to MySQL 8.4 introduces significant improvements in performance, security, observability, and operational efficiency while maintaining backward compatibility for most workloads.
The upgrade process uses a blue-green deployment approach, where a new MySQL 8.4 database service is provisioned, synchronizes the data from the existing MySQL 8.0 service using native MySQL InnoDB ClusterSet asynchronous replication and executes a controlled application cutover during a planned maintenance window.
This approach minimizes application downtime and provides rollback options during the rollback protection period.
This guide covers prerequisites, upgrade workflow, validation steps, limitations, and rollback considerations for a successful MySQL major version upgrade on Tessell.
Benefits of Upgrading to MySQL 8.4
Upgrading from MySQL 8.0 to MySQL 8.4 LTS provides the following key benefits for your organization.
Extended Long-Term Support
MySQL 8.0 reached its end of life on April 2026, making upgrade to 8.4 essential for continued security compliance.
MySQL 8.4 provides long-term support, including security updates, bug fixes, and maintenance releases for an extended period. This reduces the frequency of major version upgrades and provides greater operational stability.
Improved Security
MySQL 8.4 includes security enhancements and fixes introduced after MySQL 8.0, helping organizations maintain compliance and reduce operational risk.
Performance Enhancements
MySQL 8.4 delivers improvements across various database operations such as Query execution efficiency, Replication performance, InnoDB storage engine optimizations, Resource utilization improvements, etc.
Improved High Availability and Replication
MySQL 8.4 includes enhancements to InnoDB Cluster, Group Replication, and ClusterSet capabilities, providing improved reliability and operational flexibility for highly available deployments.
Supported Configurations
The MySQL 8.0 to MySQL 8.4 upgrade process is supported for the following Tessell deployment configurations.
Single-instance MySQL deployments
Single-instance with Read Replica (RR) / Disaster Recovery (DR) deployments
High Availability (HA) Deployments
High Availability (HA) with Read Replica (RR) / Disaster Recovery (DR) Deployments
Prerequisites
1. Run MySQL Upgrade Checker
MySQL provides the Upgrade Checker Utility through MySQL Shell to help identify potential issues before performing a major version upgrade.
Users should run the Upgrade Checker using the target MySQL Shell version (8.4) against the source MySQL 8.0 database.
The Upgrade Checker evaluates:
Deprecated or removed configuration parameters
Authentication plugin compatibility
Reserved keyword conflicts
Unsupported SQL syntax
Invalid metadata
Privilege-related issues
Compatibility concerns between MySQL 8.0 and MySQL 8.4
Example:
Review the generated report and remediate all identified issues before proceeding with the upgrade.
Ignoring Upgrade Checker findings may result in upgrade failures, application issues, or unexpected behavior after migration.
Customers are encouraged to validate application compatibility before upgrading to production environments.
2. Provision MySQL 8.4 Service on Tessell
Ensure that the target MySQL 8.4 database service is provisioned with a configuration similar to the source MySQL 8.0 service, including HA, RR and DR nodes.
3. Validate MySQL Client and Driver Compatibility
Before upgrading to MySQL 8.4, customers should review and validate the compatibility of all MySQL client software, connectors, drivers, ORM frameworks, and database tools used by their applications.
Customers should upgrade any unsupported or outdated client components and perform application testing against a MySQL 8.4 environment before the production cutover.
Failure to validate client compatibility may result in connection issues, authentication failures, or application errors after the upgrade.
4. Validate Rollback Procedures
Before proceeding with the production upgrade, ensure that a rollback strategy has been defined, reviewed, and agreed upon by all stakeholders.
It is strongly recommended to review and test rollback procedures in a non-production environment before performing the production upgrade.
Figure 1 : MySQL 8.0 Source Environment and MySQL 8.4 Target Environment
Preparing Source Database
Ensure network connectivity between the source and target database services.
Provision a transition replica cluster (RR) from source 8.0 service and this RR will be used to facilitate data synchronization between the MySQL 8.0 and MySQL 8.4 environments.
Upgrade MySQL Shell client binary from 8.0 to 8.4 on Source node(s) which includes HA, RR or DR nodes.
Before introducing MySQL 8.4 nodes into the replication topology, the InnoDB ClusterSet metadata must be upgraded to a version that supports MySQL 8.4. Connect to the active MySQL 8.0 primary cluster using MySQL Shell and execute the
dba.upgradeMetadata()operation. This updates the ClusterSet metadata schema to a version that is compatible with MySQL 8.4 and enables the addition of MySQL 8.4 cluster members to the existing topology.
Figure 2 : Creating a Transition Replica (RR) from the Source Environment
Preparing Target Database
Ensure network connectivity between the target and source database services.
Verify that all required application IP addresses and CIDR ranges are allowed to connect to the target service.
Upgrade MySQL Server to 8.4 on Source Replica Cluster (RR)
As part of the upgrade process, Tessell upgrades the transition replica to MySQL 8.4 version. This replica acts as an intermediary between the source MySQL 8.0 environment and the target MySQL 8.4 environment.
Stop MySQL Service on Source RR node.
Deploy desired MySQL 8.4.X Binary.
Start MySQL Service on Source RR node.
Review the MySQL error log and confirm that the server upgrade completed successfully.
Verify that the upgraded transition source RR replica cluster is healthy and fully synchronized.
Figure 3 : Upgrading the Transition Replica (RR) to MySQL 8.4
Add the Target MySQL 8.4 Service to the ClusterSet
After the transition source replica (RR) has been upgraded successfully, the target MySQL 8.4 service is integrated into the existing ClusterSet topology.
Once the target MySQL 8.4 service has been successfully added, it remains synchronized with the source MySQL 8.0 environment until the application cutover is performed.
Figure 4 : Integrating Target MySQL 8.4 Service into the ClusterSet
Considerations for Target Read Replica and Disaster Recovery Clusters
If the target environment includes Read Replica (RR) or Disaster Recovery (DR) clusters, RR and DR clusters cannot be attached to the ClusterSet while the source MySQL 8.0 cluster remains the primary ClusterSet member.
These RR/DR replica clusters can be attached after the application cutover has been completed and the source MySQL 8.0 cluster has been detached from the ClusterSet.
Post-Upgrade Validation
Before scheduling the application cutover, validate that the target MySQL 8.4 environment is operating as expected.
Verify the following:
Automated backups are functioning successfully.
Monitoring dashboards are reporting database metrics in Tessell Console.
Database logs are accessible through the Tessell Console.
Point-in-Time Recovery (PITR) functionality is operational.
Replication between the source and target environments is healthy and fully synchronized.
Increase the binlog retention on both source and target services to support rollback procedures.
Application Cutover
The application cutover is the final stage of the upgrade process where application traffic is redirected from the MySQL 8.0 environment to the MySQL 8.4 environment.
Take a pre-upgrade backup of the source MySQL 8.0 service.
Gracefully shut down the application services to prevent new write activity on the source database.
Confirm that no application sessions remain connected to the source database.
Ensure there is no replication lag between source and target service.
Promote the target MySQL 8.4 environment as the active primary cluster and this will automatically make source 8.0 cluster as read replica cluster.
Update application connection endpoints to point to the target MySQL 8.4 service.
Start the application service.
Perform application sanity checks.
Monitor closely for errors or performance issues.
If the target environment has RR or DR node which was detached in the preparation steps, add them back into the ClusterSet during low traffic hours.
After 24 hours, detach the MySQL 8.0 service from ClusterSet topology and drop the service from Tessell UI.
Figure 5 : Promoting Target MySQL 8.4 Service to Primary Role
Figure 6 : Removing the MySQL 8.0 Service from the ClusterSet
Rollback Approaches
In the event of application incompatibility, performance issues, or operational concerns after upgrading to MySQL 8.4, the following rollback approaches can be used to return the workload to MySQL 8.0.
Important: A rollback plan should be agreed upon and validated before starting the production upgrade activity.
The following rollback options are available.
Option 1: Native MySQL Replication-Based Rollback
Tessell supports a rollback protection period of 24 hours during which the original MySQL 8.0 environment remains available and synchronized with the upgraded MySQL 8.4 environment.
If issues are identified after the cutover, application traffic can be redirected back to the MySQL 8.0 environment with minimal downtime.
Considerations
Replication from MySQL 8.4 to MySQL 8.0 is supported only when all replicated SQL statements remain compatible with MySQL 8.0.
During the rollback protection period:
Avoid executing DDL statements that may not be compatible with MySQL 8.0.
Avoid enabling MySQL 8.4 features that are unavailable in MySQL 8.0.
Avoid creating objects that are unsupported in MySQL 8.0.
Ensure replication remains healthy throughout the rollback protection period.
For additional information, please refer to the MySQL Documentation on replication compatibility between versions.
Option 2: AWS DMS CDC-Based Rollback
AWS Database Migration Service (DMS) can be used to maintain a Change Data Capture (CDC) replication stream from the upgraded MySQL 8.4 database back to a MySQL 8.0 database during the rollback protection period.
This approach allows the MySQL 8.0 environment to remain synchronized with changes occurring on the MySQL 8.4 database, providing an additional rollback mechanism if issues are identified after the upgrade.
If AWS DMS Change Data Capture (CDC) replication is planned as a rollback mechanism from MySQL 8.4 to MySQL 8.0, perform a DMS Pre-Migration Assessment before starting the upgrade.
The assessment helps identify:
Unsupported data types
Schema compatibility issues
Replication limitations
Potential CDC-related challenges
LimitationsBefore choosing AWS DMS CDC as a rollback strategy, consider the following limitations:
Invisible Primary Keys (Generated Invisible Primary Keys - GIPK) are not supported by AWS DMS. Tables relying on invisible primary keys may not replicate correctly.
DDL operations are not replicated by AWS DMS CDC. Any schema changes performed on MySQL 8.4 must be manually applied to the MySQL 8.0 rollback environment.
MySQL 8.4-specific features, syntax, and objects that are unsupported in MySQL 8.0 may cause replication failures.
Changes involving incompatible data types or metadata structures may not be replicated successfully. For more details, please refer the AWS DMS documentation given below.
Option 3: Logical Dump and Restore - Based Rollback
This approach involves taking a logical backup from the MySQL 8.4 environment and restoring it into a MySQL 8.0 environment. While this method provides a reliable rollback mechanism, it can significantly increase application downtime, as both the backup and restore operations must be completed before the application can be brought back online.
The overall rollback duration depends on factors such as database size, available compute resources, storage performance, and network throughput.
Example:
For a database size of approximately 1 TB, the logical backup process may take 6–12 hours, depending on the available system resources and the backup utility used. The restore operation typically takes longer than the backup process and may require up to 2x the backup duration, resulting in an estimated restore time of 12–24 hours.
Therefore, this rollback approach should be considered only when other rollback options are not feasible, given its potential impact on application availability and recovery timelines.
Last updated
Was this helpful?