MySQL 8.0 to 8.4 Upgrade: What Breaks and How to Do It Safely

A MySQL 8.0 to 8.4 upgrade looks like a minor step: same "8" in the name, an in-place upgrade supported by Oracle, and 8.0 is already out of support. On a test server it often takes minutes. In production the trouble comes from everything around the server: an application account that suddenly can't log in, a monitoring script that runs SHOW SLAVE STATUS, a my.cnf with an option that no longer exists, and InnoDB defaults that changed under your workload. None of this is hard to fix if you find it before the upgrade.

Why now

Oracle ended support for MySQL 8.0 in April 2026, which means no more security fixes from Oracle for it. MySQL 8.4 is the LTS release that follows it and the natural target for most production systems. If you are wondering whether to skip ahead to 9.7 LTS or the new calendar-versioned releases, our guide to MySQL versions after 26.10 covers that choice. This article is about getting from 8.0 to 8.4 without an outage.

Supported upgrade paths

According to the MySQL upgrade paths table, moving from an 8.0 release to 8.4 LTS is supported with three methods:

• In-place upgrade: stop 8.0, install 8.4 binaries on the same data directory, start. The server upgrades the data dictionary and system tables on first start.
• Logical dump and load: export from 8.0, import into a fresh 8.4 server. Slow on large databases, but it gives you a clean new instance.
• Replication: build an 8.4 replica of your 8.0 primary, let it catch up, then switch over.

MySQL Clone is listed only for upgrades within a series, so it is not a way to go from 8.0 to 8.4. For a replication topology the manual describes a rolling upgrade: replicas first, then the primary.

What breaks: authentication

This is the change that most often turns an upgrade into an incident. Starting with 8.4.0, the deprecated mysql_native_password plugin is no longer enabled by default. Accounts that still use it can't log in until you either move them to caching_sha2_password or enable the old plugin with mysql_native_password=ON in the [mysqld] section.

Find these accounts on 8.0 before the upgrade:

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

Moving accounts to caching_sha2_password is the right long-term fix, but test every client first. Old drivers, some ORMs, BI tools and legacy applications may not support it, or need TLS or an RSA key exchange to use it. Enabling mysql_native_password temporarily is a reasonable way to decouple the server upgrade from the client work, as long as someone owns the follow-up.

Related: default_authentication_plugin has been removed. Use authentication_policy instead, and note that its syntax has changed.

What breaks: removed commands and options

MySQL 8.4 finishes the move away from MASTER/SLAVE terminology. These statements now return a syntax error:

• SHOW SLAVE STATUS → SHOW REPLICA STATUS
• START SLAVE / STOP SLAVE / RESET SLAVE → START / STOP / RESET REPLICA
• CHANGE MASTER TO → CHANGE REPLICATION SOURCE TO, and all MASTER_* options become SOURCE_*
• SHOW MASTER STATUS → SHOW BINARY LOG STATUS
• RESET MASTER → RESET BINARY LOGS AND GTIDS
• FLUSH HOSTS → TRUNCATE TABLE performance_schema.host_cache

The server is usually the easy part. The real work is finding every place that uses the old commands: monitoring checks, backup scripts, failover tooling, Ansible roles, runbooks. A lag check that fails with a syntax error tends to look like "replication is fine" on a dashboard, which is worse than an alert. If you rely on replica health checks, see how we monitor them in our MySQL replication lag guide.

Several server options are gone too, and setting them in 8.4 raises an error. Among those that still appear in many 8.0 configs: default_authentication_plugin, binlog_transaction_dependency_tracking, --ssl, master_info_repository and relay_log_info_repository, slave_rows_search_algorithms, --skip-host-cache and transaction_write_set_extraction. Clean them out of the config before the upgrade, not during it.

What changes quietly: InnoDB defaults

A number of InnoDB default values changed in 8.4.0. If you set these explicitly, nothing changes for you. If you relied on defaults, your server behaves differently after the upgrade:

• innodb_io_capacity: 200 → 10000. Background flushing becomes much more aggressive. Good on fast SSD or NVMe, worth reviewing on slow or throttled cloud volumes.
• innodb_adaptive_hash_index: ON → OFF.
• innodb_change_buffering: all → none.
• innodb_flush_method on Linux: fsync → O_DIRECT where supported.
• innodb_log_buffer_size: 16 MiB → 64 MiB.
• innodb_buffer_pool_instances, read and write I/O threads, purge threads and page cleaners are now calculated from buffer pool size and CPU count instead of fixed numbers.

These new defaults are sensible for modern hardware, but "sensible on average" is not the same as "same as before". Compare performance on a realistic workload before production, and if something regresses, you know which knobs to look at first.

A safe upgrade plan

1. Upgrade to the latest 8.0 release first, so you start from a fully patched server.
2. Run the upgrade checker. MySQL Shell's upgrade checker is recommended by the manual and runs the automated checks for your target version:

   mysqlsh -- util checkForServerUpgrade root@db-host:3306 --target-version=8.4.0

   Fix every error and read every warning. The preparation checklist also lists manual checks, such as obsolete data types, orphan .frm files and triggers with a missing definer.
3. Clean the config. Remove deleted options, and decide explicitly about the InnoDB settings above instead of inheriting new defaults by accident.
4. Fix clients. Find mysql_native_password accounts and test drivers, and update scripts and monitoring to the new replication commands. SHOW REPLICA STATUS, START/STOP REPLICA and CHANGE REPLICATION SOURCE TO already work on recent 8.0 releases, so you can switch them before the upgrade. SHOW BINARY LOG STATUS and RESET BINARY LOGS AND GTIDS only exist from 8.2, so those change together with the server.
5. Test with production-like data and traffic. Restore a recent backup onto an 8.4 test server, run the application's test suite and replay realistic load. Compare slow query logs.
6. Upgrade replicas first. Upgrade one replica, put read traffic on it, watch for errors and latency changes. Then upgrade the rest.
7. Switch the primary. Promote an 8.4 replica in a planned maintenance window, or upgrade the old primary in place. Keep an 8.0 server replicating, or a verified backup, as the rollback path until you are confident.

Managed MySQL

On RDS, Cloud SQL and Azure, the provider handles the binaries, but not the compatibility issues. Authentication, removed statements in your scripts and changed parameter defaults still apply, and providers usually have their own parameter groups and timelines, sometimes with extra fees for running older versions. Check your provider's documentation for its 8.4 parameter defaults, and use a blue/green or replica-based upgrade where it is offered.