MySQL 8.0 leaves standard support: moving to 8.4 LTS

What happened to MySQL 8.0

In spring 2026 Oracle moved MySQL 8.0 into Sustaining Support mode: the branch no longer receives regular maintenance. The server will not stop and your data will not vanish, but you can no longer count on the usual stream of fixes. Oracle advises moving to 8.4 LTS or 9.7 LTS, and it is wiser to do that on a schedule than after the first vulnerability.

Sources name the exact date differently: some give 21 April 2026, others 30 April. We could not open Oracle’s notice page directly, so this article says only "spring 2026". Check the date yourself on Oracle’s notice page. The last release of the 8.0 branch on the download page is 8.0.46 (as of early November 2026).

Where to move: 8.4 LTS, 9.7 LTS or MariaDB

For production servers the nearest LTS series, 8.4, is the right target. According to the MySQL manual, releases are split into two tracks, LTS and Innovation; LTS gets five years of premier support and three more of extended support, and within a series only necessary fixes ship.

• MySQL 8.4 (LTS): release 8.4.13 of 20 October 2026; direct move from 8.0
• MySQL 9.7 (LTS): second LTS series; from 8.0 only via 8.4
• MariaDB 12.3 (LTS): GA on 28 May 2026, community support until 12 June 2029 (per the mariadb.org policy table)

MariaDB is not an upgrade of MySQL but a change of server: compatibility is incomplete, and it is a separate migration. Its advantages and pitfalls are covered in the article on moving between MariaDB and MySQL.

The series rule: what you cannot skip

An LTS series cannot be skipped. So 8.0 → 8.4 is allowed directly, and so is 8.4 → 9.7, but 8.0 → 9.7 only via 8.4. Version 5.7 reaches 8.4 only through 8.0; that step is described in the article on upgrading from 5.7 to 8.0.

What breaks: authentication and removed options

The main risk of the upgrade is not the data but old connections and configs. In 8.4 the mysql_native_password plugin is not enabled by default, and the default_authentication_plugin option is removed: authentication_policy takes its place. Applications with old accounts will not be able to log in until you migrate the users or enable the plugin.

-- accounts that are still on the old plugin
SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';

-- move an account to the default plugin
ALTER USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'CHANGE_ME';

# my.cnf: a temporary measure until the applications are migrated
[mysqld]
mysql_native_password=ON

In addition, 8.4 removes:

• mysql_upgrade and mysqlpump (take dumps with mysqldump; the server performs the startup check itself);
• the options --skip-host-cache, --innodb and --skip-innodb, --ssl and --admin-ssl;
• the SET_USER_ID privilege and the plugins keyring_file, keyring_encrypted_file, keyring_oci, openssl_udf, authentication_fido.

Separately, AUTO_INCREMENT on FLOAT and DOUBLE columns will block the upgrade until you rebuild such tables, and foreign keys on non-standard keys are forbidden by default (the restrict_fk_on_non_standard_key option). The full list is in the MySQL 8.4 manual, in the section on upgrading from the previous series.

Replication: statements renamed

If you run replication, prepare your scripts in advance: the old statements with the terms master and slave are removed in 8.4, which breaks monitoring, cron jobs and on-call instructions. The replacement is direct; only the names change.

The options master-info-repository and relay-log-info-repository are also removed, together with transaction_write_set_extraction and log_bin_use_v1_events. Find them in my.cnf in advance: an unknown option will keep the server from starting.

Changed default values

These options do not block startup, but they change behaviour and load: with the same settings the database may act differently. If you did not set them in my.cnf yourself, the 8.4 server takes the new values. You can pin the old behaviour explicitly, but first measure whether you need it.

The values come from the MySQL 8.4 manual. To restore the old behaviour, set what you need in my.cnf; tuning the remaining options is covered in the article on optimising my.cnf.

Compatibility check before upgrading

Before changing anything, run the check: MySQL Shell finds in advance the problems that would break the upgrade. The util.checkForServerUpgrade() utility works with 5.7 and 8.x servers and needs the PROCESS and SELECT privileges. Name the target release explicitly, and use a MySQL Shell version no lower than the target.

mysqlsh -- util checkForServerUpgrade user@host:3306 --target-version=8.4.13 --output-format=JSON

Work through the report from top to bottom and match it against the sections above. Start with the errors: they will stop the upgrade, while the warnings can wait until you test on a copy.

Upgrade order with a backup and a rollback

A safe order is: check, full backup, stop writes, upgrade, verify. Plan the rollback before you start: do not count on a reverse upgrade on the same data files, the reliable way back is the backup. Backup techniques are covered in the article on mysqldump.

1. Run util.checkForServerUpgrade() and fix every error.
2. Take a logical dump and a copy of the data directory on a stopped server.
3. Confirm on a separate machine that the backup restores.
4. Remove the deleted options from my.cnf, migrate the users or temporarily enable mysql_native_password.
5. Stop the server, upgrade the packages to 8.4 and start it.
6. Read the error log, connect the application and run control queries.
7. After a few days, remove the temporary measures.

mysqldump --all-databases --single-transaction --routines --events --triggers > /backup/all-before-84.sql
systemctl stop mysql
cp -a /var/lib/mysql /backup/mysql-datadir-before-84

The service name depends on the distribution: mysql or mysqld. Rollback: stop the 8.4 server, restore the data directory copy and the 8.0 packages, and start it. Writes made after the upgrade have to be carried over by hand, so keep the application read-only while you verify.

Frequently asked questions

Will MySQL 8.0 stop working immediately?

No. The server keeps running, but the branch no longer receives regular maintenance. Plan the move ahead of time, while there is room to test on a copy.

Can I go from 8.0 straight to 9.7?

No, an LTS series cannot be skipped. First 8.0 → 8.4, then 8.4 → 9.7, each step with its own check and backup.

Do I need to run mysql_upgrade after the upgrade?

No, that program is removed in 8.4. The server checks and upgrades the system tables itself on first start and writes the result to the error log.

What should ZevsHost customers do?

On shared hosting the panel manages the MySQL version, so there is nothing for you to do. On a VPS or dedicated server the database server is yours to run: take a backup and check compatibility before upgrading.