QueryKings

MySQL 8.0 is going out of support: planning the move to 8.4 LTS

Most teams we talk to finished the 5.7 to 8.0 upgrade recently enough that it still stings. The news is that 8.0 is not the destination. Oracle's premier support for MySQL 8.0 ends in April 2026, and the version that replaces it as the long-term target is 8.4 LTS. If your production estate is on 8.0 today, you have a second upgrade to plan — a much smaller one than the last, but not a zero.

This is a planning guide, not a release-notes summary. Check every version number against the release notes for your exact starting point before you schedule anything; the details below move with the point releases.

The release model, briefly

Since 8.1, MySQL ships in two tracks:

  • LTS releases (8.4, and the next one after it) get bug fixes for years and, critically, do not change behavior between point releases. 8.4 carries roughly five years of premier support followed by extended support.
  • Innovation releases (8.1 through 8.3, then 9.x) ship features quickly and are supported only until the next release appears. They can change defaults and remove things at any point.

The practical reading for a production database: track LTS. Innovation releases are for teams that want a specific new feature and can accept upgrading every quarter forever. We have not yet met a client whose MySQL workload justified that cadence.

So the plan for nearly everyone on 8.0 is: go to 8.4, stay there, and revisit when the next LTS lands.

The path

Upgrades to 8.4 are supported from 8.0 — and you want to be on a recent 8.0 point release before you start, not on 8.0.19 from four years ago. Get to the latest 8.0 first as a separate, boring change, then upgrade to 8.4. Two small steps, each independently revertible, beat one big one.

If you are still on 5.7, there is no direct hop. 5.7 to 8.4 is not a supported in-place path: you go 5.7 to 8.0, then 8.0 to 8.4. Our earlier walkthrough of the 5.7-to-8.0 traps still applies to that first leg unchanged — and if you are only starting now, plan both legs in one project with one rollback story rather than treating the second as future work.

Also worth stating plainly: in-place downgrade between major versions is not supported. "Roll back by reinstalling the old binaries" is not a plan. Rollback comes from replication topology, which is the section below.

Defaults that change under you

The 8.0 to 8.4 jump is mostly a defaults-and-removals release rather than a data-dictionary rewrite like 8.0 was. The changes that actually cause incidents:

mysql_native_password is disabled by default. The plugin still exists in 8.4 but is off unless you enable it explicitly, and it is on track for removal entirely. Any old client, connector, or automation account still authenticating with it will fail to connect the moment you cut over. Inventory this before the upgrade:

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

Then check the client side too: connectors older than the caching_sha2 era, and any driver connecting without TLS that cannot do the RSA key exchange, need upgrading or a documented exception. This is the single most common cause of a failed 8.4 cutover we see, and it is entirely discoverable a month in advance.

Semi-synchronous replication moved from plugins to components. The old rpl_semi_sync_master / rpl_semi_sync_slave plugins are replaced by the semi-sync components, with new variable names. If your HA depends on semi-sync acks, your configuration management and your monitoring queries both need rewriting, and the old variable names in a config file will stop the server from starting.

Parallel replication defaults changed. replica_parallel_workers now defaults to a value greater than one, and writeset-based dependency tracking is the default behavior rather than something you opt into. For most estates this is a free improvement — it is the change that fixes lagging replicas without a bigger instance. But if you had carefully tuned single-threaded apply for ordering reasons, verify replica_preserve_commit_order is doing what you expect on read paths that assume it.

Removed options and utilities. A batch of long-deprecated server variables and command-line options are gone, and an unknown variable in my.cnf is a startup failure, not a warning. mysqlpump is removed; if any backup or export script calls it, replace it with mysqldump or a physical-backup path first. Keyring plugins give way to keyring components — relevant if you use encryption at rest on self-managed servers.

Deprecation notices worth reading as roadmap. binlog_format and the non-row formats are on the way out, as is the older GRANT-era behavior in a few corners. Nothing breaks in 8.4, but if you are still running STATEMENT or MIXED binlog format, treat this upgrade as the deadline for moving to ROW — plenty of other things, including writeset parallelism and most migration tooling, want row format anyway.

Managed platforms shift the calendar, not the work

On RDS and Aurora you do not choose your patch level, but you do choose your major version, and the provider's own end-of-standard-support dates for MySQL 8.0 drive your timeline more directly than Oracle's. Two things to check early:

  • Which 8.4 versions your platform actually offers, and whether the features you use are available there. Aurora tracks upstream on its own schedule; parity is not automatic.
  • Whether the provider will auto-upgrade you at EOL. An automatic major-version upgrade applied during a maintenance window you did not choose, with authentication changes you did not audit, is a bad night. Upgrading on your own schedule is the cheap way to avoid it.

The pre-flight work — plugin audit, config audit, tooling audit, performance verification — is identical whether you run the server yourself or not. Only the mechanics of the cutover differ.

Testing that finds the real problems

The upgrade checker in MySQL Shell (util.checkForServerUpgrade()) is the mandatory first pass and takes minutes. It catches removed variables, orphaned objects, reserved-word collisions, and character-set issues. It does not catch performance regressions or connector failures, so it is a floor rather than a plan.

The two tests that earn their cost:

  1. A plan-and-latency comparison on real queries. Capture a representative slow-query sample from production, run it against an 8.4 copy with production-sized data and statistics, and diff both the EXPLAIN output and the execution times. Optimizer changes between versions are usually improvements, and occasionally a query that relied on a specific plan gets slower. You want to find those three queries in a test, with time to add an index or a hint, rather than at 9 a.m. on cutover day.
  2. A full connector pass. Every application, every worker, every cron job, every BI tool, every operator laptop — connect each one to the 8.4 test instance with production-shaped credentials. This is tedious and it is where the authentication surprises surface.

The cutover, with a rollback that exists

Our standard mechanism for a major-version move is replication-based, because it is the only shape that gives you a real way back:

  1. Build an 8.4 replica of the 8.0 primary. Cross-version replication from an older source to a newer replica is supported in this direction, which is what makes the whole approach work.
  2. Let it run in parallel for days, not hours. You are watching apply lag, error logs, and — if you can mirror read traffic to it — query latency against the live baseline.
  3. Cut over writes during a short pause: stop writes, let the replica catch up to the final position, promote it, repoint the application. Seconds of write pause, not a window.
  4. Keep the old 8.0 primary alive and, where the topology allows, replicating from the new 8.4 primary for the rollback period. Replication from a newer source to an older replica is not supported in general, so verify what works for your specific pair and workload during rehearsal; where it does not, your fallback is a documented restore point plus a change-capture log. Either way, decide the rollback mechanism before the cutover and test it, rather than discovering after promotion that there is no way back.
  5. Set an explicit decommission date for the old primary. Rollback windows that never close become permanent, expensive shadow infrastructure.

The same discipline applies to replicas: upgrade them first, one at a time, and let each serve read traffic on 8.4 for a while before you touch the primary. By the time the primary moves, 8.4 has already been running your production read workload for a week.

What to do this quarter

If you are on 8.0 and April 2026 sounds distant, the honest sequence is short:

  • Run the upgrade checker against production this week. It is read-only and it takes minutes.
  • Run the mysql_native_password query above and start the connector inventory. This is the long-lead item, because it involves other teams.
  • Get to the latest 8.0 point release as ordinary patching.
  • Schedule the 8.4 work for a quarter where it is not competing with a launch.

Upgrade debt compounds quietly: the 5.7 estates that ended up in an emergency were, without exception, estates where the upgrade kept losing to feature work until support ended. The 8.0 to 8.4 move is genuinely smaller than the last one. It is worth doing while it is still small.

If you want a second set of eyes on the plan — the pre-flight audit, the cutover design, or the rollback rehearsal — that is the kind of engagement we run every month.