maborak.com~/blog/mysql-8-eol-upgrade-probesoftware & infrastructure engineering
Back to all articles

MySQL 8.0 is out of support: an upgrade probe for 8.4 LTS

MySQL 8.0 reached end of life in April 2026. Three queries that find the accounts, plugins and replication state blocking an 8.4 upgrade.

By the Maborak engineering team · · 3 min read

MySQL 8.0 reached end of life in April 2026. The supported paths are the 8.4 long-term release, or a move to MariaDB. The upgrade is usually not blocked by the engine; it is blocked by accounts that still authenticate with an old plugin and by client libraries that cannot speak the new one.

Checked 29 October 2026. The end-of-life month is from the published lifecycle tracker; confirm the exact date and the support level for your edition against Oracle’s lifecycle page. Plugin and upgrade behaviour is from the MySQL 8.4 documentation.

Background

MySQL releases in two tracks: long-term support releases, where 8.4 succeeded 8.0, and innovation releases, which add features and are not for production. 8.0 spent years as the default deployment target, so a large share of installations still carry accounts created under mysql_native_password, the pre-8.0 default authentication plugin.

Mechanics

Two changes cause most failed upgrades:

  • Authentication plugin. MySQL 8.4 disables mysql_native_password by default. Accounts that still use it cannot authenticate until they are converted to caching_sha2_password, or until the plugin is explicitly re-enabled. The client side matters too: an old libmysqlclient or an application driver that does not support caching_sha2_password will fail after the server change.
  • Removed and deprecated features. The 8.4 upgrade notes list options and syntax that are removed. A my.cnf copied forward can stop the server from starting if it contains a removed option.

The server can be upgraded as a replica before the primary changes: update the replica, let it catch up, promote it, then upgrade the old primary as the new replica. That keeps a rollback target.

Impact

An unsupported engine keeps receiving no fixes. The upgrade itself can lock out application accounts, which is an outage even when the database is healthy. Inventory the clients before the server.

Probe

Run these against a read-only replica or a restored copy. The first two are safe on production; the third changes nothing but reads replication state.

SELECT VERSION() AS version, @@version_comment AS build;

SELECT plugin, COUNT(*) AS accounts
FROM mysql.user
GROUP BY plugin
ORDER BY accounts DESC;

SELECT user, host, plugin
FROM mysql.user
WHERE plugin <> 'caching_sha2_password';

Replication state, on a replica:

SHOW REPLICA STATUS\G

The MySQL Shell upgrade checker is the closest thing to a dry run. It reads the data dictionary without modifying it:

mysqlsh -- uri [email protected] -- util checkForServerUpgrade --target-version=8.4

The output is a list of findings, not a verdict. The useful result is: count of accounts on mysql_native_password, any removed configuration options, and any replication filter that the new version rejects.

Mitigation

  1. Convert accounts one at a time and confirm each client can log in: ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY '…';
  2. Upgrade client libraries and drivers before or with the server. A server that accepts a password the client cannot hash is still down.
  3. Remove deprecated options from configuration; start from the 8.4 defaults where possible.
  4. Upgrade a replica first, promote it, then rebuild the old primary. Keep the 8.0 data directory and binaries until the new primary has served normal traffic.

If the application stack is the blocker, MariaDB 11.8 LTS is the other path. It is a migration, not an in-place upgrade: dump and restore, and test the SQL differences.

Verification

SELECT @@version, @@version_comment;
SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
SHOW REPLICA STATUS\G

Then exercise a real login from each application host, a write, a read replica query and a backup restore. A version string proves the engine changed, not that the application still works.

Sources

Back to all articles

Technologies we work with

  • Argo CD
  • Kubernetes
  • Docker
  • Podman
  • Ansible
  • Jenkins
  • Chef
  • Proxmox VE
  • Google Cloud
  • Linux
  • Red Hat
  • CentOS
  • NGINX
  • Apache
  • Traefik
  • Prometheus
  • Grafana
  • PostgreSQL
  • MySQL
  • MariaDB
  • Redis
  • etcd
  • Qdrant
  • Elasticsearch
  • Logstash
  • Kibana
  • PagerDuty
  • Go
  • Python
  • FastAPI
  • PHP
  • TypeScript
  • React