Transitioning to MySQL 8.4 LTS

For many organizations, upgrading to MySQL 8.4 LTS is not merely a routine version upgrade. It represents the transition from years of accumulated technical debt, deprecated features, and legacy application behaviors into a platform that enforces stricter security, metadata validation, and operational standards.

This migration has become an immediate priority for teams running on the cloud, as Amazon RDS for MySQL 8.0 will reach its End of Standard Support on July 31, 2026. Upgrading to MySQL 8.4 LTS prior to this date is essential to avoid being automatically enrolled in expensive AWS Extended Support charges.

Unlike previous minor upgrades where most deprecated functionality continued to work with warning messages, MySQL 8.4 begins actively rejecting configurations, authentication methods, metadata structures, and operational patterns that were previously tolerated.

As a result, DBAs performing upgrades from MySQL 5.7 or early MySQL 8.0 releases may encounter startup failures, application authentication issues, replication breakages, and even upgrade aborts caused by dictionary inconsistencies.

Amazon RDS EOL

Standard support for MySQL 8.0 on Amazon RDS finishes on July 31, 2026. Prevent automatic, compounding Extended Support pricing.

Support Cost Projection Profile

Standard Support vs. Extended Support pricing trajectory.

In this article, we examine the major incompatibilities introduced in MySQL 8.4 from a production DBA perspective. Rather than simply listing deprecated features, we focus on understanding what actually breaks, how to identify affected systems before the upgrade window, and the remediation steps required to ensure a successful migration.

mysql_native_password Is Disabled by Default

Authentication is one of the areas where MySQL 8.4 introduces a change that can have an immediate and visible impact on production workloads.

For more than a decade, `mysql_native_password` has been the default authentication mechanism used across MySQL deployments. Thousands of applications, monitoring tools, proxy layers, replication environments, and operational scripts have been built around this authentication plugin. As a result, many organizations still maintain a significant number of accounts using `mysql_native_password`, even after migrating to MySQL 8.0.

• Starting with MySQL 8.4, Oracle has changed this behavior by disabling the `mysql_native_password` plugin by default. Although the plugin binary still exists in MySQL 8.4, it is no longer automatically loaded during server startup.
• This change is part of Oracle's long-term strategy to move all deployments toward stronger authentication mechanisms such as `caching_sha2_password`, which has been the default authentication plugin since MySQL 8.0.
• At first glance, this may appear to be a simple security enhancement. However, from an operational perspective, this change has the potential to cause widespread application outages immediately after an upgrade.

What can break?

Consider a typical production environment running MySQL 8.0:

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

Example output:

+----------------+-----------+-----------------------+
| user           | host      | plugin                |
+----------------+-----------+-----------------------+
| mydbops        | 10.1.20.% | mysql_native_password |
| admin          | localhost | mysql_native_password |
| replication    | 10.1.20.% | mysql_native_password |
| proxysql       | 10.1.20.% | mysql_native_password |
+----------------+-----------+-----------------------+

After upgrading to MySQL 8.4, the server itself may start successfully. However, when applications attempt to authenticate using accounts configured with `mysql_native_password`, authentication will fail because the plugin is no longer loaded.

Typical error messages include:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

or on the client side:

Authentication plugin 'mysql_native_password' cannot be loaded

Authentication plugin 'mysql_native_password' cannot be loaded

In practice, this issue can impact:

• Legacy PHP applications
• Older Java JDBC connectors
• ProxySQL deployments
• Replication users
• Monitoring tools
• Backup utilities
• ETL platforms
• Third-party vendor applications

One of the more dangerous aspects of this change is that the database upgrade itself appears successful. The outage is only discovered when applications begin reconnecting after the maintenance window.

Recommended remediation

The preferred long-term solution is to migrate all accounts to `caching_sha2_password`:

ALTER USER 'app_user'@'10.1.20.%' IDENTIFIED WITH caching_sha2_password BY 'StrongPassword';

After migration, validate connectivity from:

• Application servers
• Replication channels
• Proxy layers
• Monitoring agents
• Backup servers

Organizations that cannot immediately migrate all applications can temporarily enable the plugin in MySQL 8.4 by adding the following block to my.cnf:

[mysqld]
mysql_native_password=ON

However, this should only be considered a short-term compatibility measure because Oracle has already announced the complete removal of `mysql_native_password` in future MySQL releases. For most organizations, the MySQL 8.4 upgrade should be viewed as the final opportunity to eliminate dependency on legacy authentication mechanisms.

Removal of default_authentication_plugin and Other Legacy Configuration Parameters

One of the most common causes of upgrade failures is not application incompatibility or data corruption—it is configuration drift.

• Most MySQL environments have evolved over many years. Configuration files are often copied from older deployments, inherited through automation frameworks, or reused across multiple projects. As a result, it is common to find configuration parameters originally introduced in MySQL 5.5 or MySQL 5.6 still present in production environments running MySQL 5.7 / 8.0.
• Historically, MySQL tolerated many deprecated configuration options for several release cycles before removing them. MySQL 8.4 continues Oracle's effort to clean up obsolete server parameters, which means that certain configuration options that previously generated warnings will now cause the server startup process to fail.

The most notable example is:

default_authentication_plugin=mysql_native_password

This parameters became extremely popular during the MySQL 8.0 adoption phase because organisations wanted to retain compatibility with applications that could not yet support `caching_sha2_password` it.

However, beginning with MySQL 8.4, these variable no longer exists.

What can break?

Consider the following production configuration:

[mysqld]
default_authentication_plugin=mysql_native_password

After upgrading to MySQL 8.4, the MySQL server will fail during initialization:

[ERROR] unknown variable
'default_authentication_plugin=mysql_native_password'
[ERROR] Aborting

The server never completes startup. This issue frequently affects environments using:

• Ansible playbooks
• Puppet manifests
• Chef cookbooks
• Kubernetes ConfigMaps
• Docker images
• Terraform deployments
• Cloud-init scripts
• Legacy DBA automation repositories

Unfortunately, many organizations discover these issues only during the maintenance window after the production server refuses to start.

The problem is not limited to `default_authentication_plugin`. Several environments still contain obsolete parameters such as:

• log_warnings
• expire_logs_days
• slave_parallel_workers

Depending on the parameter, MySQL may either ignore it, generate warnings, or abort startup entirely.

Recommended remediation

The safest approach is to perform a complete configuration review rather than simply removing individual parameters.

DBAs should:

• Remove obsolete configuration variables.
• Replace deprecated parameters with their supported equivalents.
• Validate configuration files in a test environment.
• Perform a complete server restart test before the maintenance window.
• Maintain version-specific configuration templates.

For example, the following parameter:

expire_logs_days=7

should be replaced with:

binlog_expire_logs_seconds=604800

Configuration debt accumulates silently over time. MySQL 8.4 is significantly less forgiving of this debt than previous releases, making configuration auditing a mandatory step in every upgrade project.

‍Foreign Keys Not Referencing a Full Unique Index

Foreign key validation is one of the areas where MySQL has gradually become more strict over successive releases. Historically, InnoDB permitted certain foreign key definitions that did not strictly comply with the SQL standard, particularly when the referenced columns were only part of a composite unique index.

• Many production environments created on MySQL 5.6, MySQL 5.7, and even early MySQL 8.0 releases continue to operate with these historical foreign key definitions without any obvious issues. However, MySQL 8.4 introduces stricter validation checks during upgrade assessment, and the MySQL Shell Upgrade Checker now explicitly validates foreign key relationships using the `foreignKeyReferences` check.
• This check identifies foreign keys that reference columns which are not backed by a fully matching unique or primary key constraint.

Why does this matter?

According to the SQL standard, a foreign key must reference a candidate key, meaning the referenced columns must collectively form either:

• a PRIMARY KEY, or
• a UNIQUE KEY

In older MySQL versions, InnoDB occasionally allowed foreign keys to reference columns that were only part of a larger composite unique index. Although these foreign keys functioned correctly from an application perspective, they violated the stricter metadata requirements now enforced by newer MySQL versions.

Consider the following example:

CREATE TABLE customers (
    customer_id INT,
    region_id INT,
    UNIQUE KEY uk_customer_region(customer_id, region_id)
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    CONSTRAINT fk_customer
        FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

At first glance, this schema appears valid. However, the referenced column `customer_id` is not independently unique. It only forms part of the composite unique key - uk_customer_region(customer_id, region_id).

As a result, MySQL Shell Upgrade Checker reports this foreign key as incompatible.

What can break?

The most common scenario is not an immediate application failure, but an upgrade validation failure. Running the upgrade checker may produce output similar to:

The following foreign keys reference columns that are not covered by a full unique index:

schema.orders.fk_customer

In some cases, future upgrades may reject these foreign key definitions entirely, forcing organizations to rebuild affected schemas before proceeding.

This issue is particularly common in environments that have experienced:

• Multiple major version upgrades
• Legacy application schemas
• Historical dump and restore operations
• ORM-generated schemas
• Manual schema modifications

The challenge for DBAs is that these schemas may have been operating successfully in production for many years before the incompatibility is discovered.

Recommended remediation:

The preferred solution is to ensure that every foreign key references a complete PRIMARY KEY or UNIQUE KEY.

For example, the following schema:

UNIQUE KEY uk_customer_region(customer_id, region_id)

can be corrected by introducing a dedicated unique constraint:

ALTER TABLE customers
ADD UNIQUE KEY uk_customer(customer_id);

Alternatively, the foreign key can be modified to reference the complete composite key:

ALTER TABLE orders
ADD COLUMN region_id INT,
ADD CONSTRAINT fk_customer
FOREIGN KEY (customer_id, region_id)
REFERENCES customers(customer_id, region_id);

The appropriate remediation depends on the application's data model and business logic.

Removed Legacy Replication Terminology

Replication administrators have historically used MASTER and SLAVE terminology throughout MySQL deployments.

Commands such as:

• SHOW SLAVE STATUS;
• START / STOP SLAVE;
• SHOW MASTER STATUS;
• CHANGE MASTER TO;

have been used for more than a decade and remain deeply embedded in operational tooling.

Beginning in MySQL 8.0, Oracle introduced inclusive replication terminology using SOURCE and REPLICA syntax. MySQL 8.4 continues this transition and further deprecates legacy terminology.

The replacement commands are:

• SHOW REPLICA STATUS;
• START / STOP REPLICA;
• SHOW BINARY LOG STATUS;
• CHANGE REPLICATION SOURCE TO;

While this may initially appear to be a cosmetic change, the operational impact can be substantial.

What breaks?

The database server itself continues to support compatibility syntax in many cases, but surrounding operational tooling frequently does not.

Commonly affected components include:

• Backup automation scripts
• Failover orchestration tools
• Health-check scripts
• Monitoring plugins
• Replication validation scripts
• Disaster recovery procedures
• Custom operational runbooks

For example, consider a typical monitoring script:

mysql -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master

After upgrading operational procedures to MySQL 8.4, teams often discover that monitoring dashboards, failover scripts, and operational playbooks require modification.

Recommended remediation

1. Perform a complete audit of your operational repositories, automation frameworks, Kubernetes operators, orchestrator hooks, and internal DBA scripts.
2. Update all replication-related statements to their modern equivalent syntax.
3. Rewrite monitoring script parser logic to look for updated status fields (e.g., Seconds_Behind_Source or relevant replica status variables).

Although MySQL maintained backward compatibility for many legacy commands across several versions, organizations must migrate entirely to SOURCE and REPLICA terminology prior to upgrading to MySQL 8.4

Deprecated Character Set Usage (utf8mb3)

Character set compatibility remains one of the most overlooked upgrade considerations.

For many years, MySQL's `utf8` character set was widely adopted under the assumption that it provided full UTF-8 support. In reality, MySQL's historical `utf8` implementation stores only three-byte UTF-8 characters and is internally represented as `utf8mb3`.

Modern applications increasingly require four-byte Unicode support for:

• Emoji characters
• Extended Unicode symbols
• International language support
• Supplemental character planes

As a result, Oracle has deprecated `utf8mb3` and strongly recommends migration to `utf8mb4`.

Why does this matter?

Although MySQL 8.4 still supports `utf8mb3`, the server generates deprecation warnings and future versions will remove support entirely.

Databases still using:

CHARACTER SET utf8

are effectively using:

CHARACTER SET utf8mb3

This can introduce several operational issues:

• Future upgrade failures
• Application encoding inconsistencies
• Character truncation
• Index length changes
• Sorting and collation differences

For example:

CREATE TABLE customer (
    name VARCHAR(255)
) CHARACTER SET utf8;

actually creates:

CHARACTER SET utf8mb3

which cannot store four-byte Unicode characters.

Recommended remediation

Convert schemas to utf8mb4 before upgrading:

ALTER DATABASE appdb
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;

Then rebuild affected tables:

ALTER TABLE customer
CONVERT TO CHARACTER SET utf8mb4;

DBAs should carefully test index lengths, collations, and application behavior after migration.

‍Data Dictionary Validation Is Much Stricter

• Perhaps the most significant architectural change introduced since MySQL 8.0 has been the transition from file-based metadata management to the transactional data dictionary.
• While MySQL 5.7 stored metadata in `.frm` files, MySQL 8.x stores metadata internally within transactional dictionary tables.
• As a result, metadata consistency requirements have become significantly stricter.

Historically, DBAs occasionally encountered situations such as:

• Orphaned `.ibd` files
• Missing tablespaces
• Corrupted dictionary entries
• Incomplete DDL operations
• Metadata inconsistencies following crash recovery
• Manual filesystem operations

Many of these issues remained hidden for years because older MySQL versions tolerated them. MySQL 8.4 no longer does.

What breaks?

During server startup or upgrade, MySQL validates metadata consistency aggressively. Typical failures include:

• Data Dictionary initialization failed
• Failed to populate DD tables
• Tablespace is missing
• Dictionary object mismatch

In severe cases, the MySQL server may refuse to start entirely. This issue is particularly common in environments that have experienced:

• Forced recovery operations
• Manual manipulation of .ibd files
• Historical storage corruption
• Interrupted DDL operations
• Multiple in-place upgrades

Recommended remediation

DBAs should never assume that historical metadata corruption will survive another upgrade.

Before upgrading to MySQL 8.4:

• Repair corrupted tables.
• Rebuild affected objects.
• Remove orphaned tablespaces.
• Validate InnoDB metadata consistency.
• Perform test upgrades using production backups.

The most reliable strategy remains performing a complete test upgrade using a recent physical backup and validating that the server can successfully initialize its data dictionary before scheduling the production maintenance window.

How to Identify Upgrade Action Items

One of the biggest mistakes organizations make during a major MySQL upgrade is treating the upgrade process as a simple binary replacement exercise. In reality, most upgrade failures occur because compatibility issues remain undetected until the production maintenance window.

Fortunately, MySQL provides an excellent pre-upgrade assessment utility through MySQL Shell's Upgrade Checker. This utility performs a comprehensive validation of the existing MySQL instance and identifies incompatibilities that may impact the upgrade process.

Before planning any MySQL 8.4 upgrade, DBAs should execute the following command against their existing environment:

mysqlsh root@localhost:3306 -- util check-for-server-upgrade

The Upgrade Checker validates numerous areas, including:

• * Deprecated and removed configuration variables
• Authentication plugin compatibility
• Foreign key reference validation
• Data dictionary inconsistencies
• Deprecated SQL syntax
• Reserved keyword conflicts
• System table integrity
• Character set compatibility
• Engine-specific incompatibilities
• Object definitions requiring remediation

Additionally, performing a QA upgrade test using a recent physical backup provides the most accurate assessment of potential production issues.

Conclusion

MySQL 8.4 LTS is not merely another incremental database upgrade. It represents a significant step toward enforcing stricter security standards, metadata consistency, and operational best practices that have evolved throughout the MySQL 8.x release cycle.

The most important takeaway is that MySQL upgrades should never be treated as an emergency activity or a last-minute maintenance task. They should be approached as planned engineering projects with proper assessment, testing, remediation, and validation phases.

Organizations that invest time in upgrade planning and compatibility assessment will typically experience smooth migrations to MySQL 8.4 while simultaneously preparing their environments for future MySQL major releases.

Avoid Costly RDS Extended Support Fees—Migrate Safely Today

With Amazon RDS for MySQL 8.0 reaching its End of Standard Support on July 31, 2026, staying on 8.0 will automatically trigger significant AWS Extended Support fees.

Use our new RDS MySQL 8.0 EOL Cost Calculator to determine your exact monthly and annual cost exposure.

Once you have your estimates, let the team at Mydbops execute a seamless transition. Our certified engineers handle your entire upgrade to MySQL 8.4 LTS, removing incompatibilities before they impact your live applications.