2026年11月13日

Migrating to MySQL 8.0: From 5.7, and the Path to 8.4 LTS

Database Servers

This article is a localized edition of the Japanese original. Read the Japanese original

When you migrate from MySQL 5.7 to 8.0, the authentication method and the default character set change, and depending on how your configuration file and user creation are written, the server may fail to start or applications may fail to connect. This article first sorts out what changes, then walks through the steps from the pre-check to verification after the migration.

Background as of November 2026

MySQL 8.0 is out of support: Oracle announced the end of life (EOL) of 8.0 for April 2026, and the last release of the 8.0 series is 8.0.46. If you are choosing a migration target now, it should be a long-term support (LTS) release, 8.4 or 9.7 (from 9.7 on, versions use a year.month format such as 26.7).
You cannot go from 5.7 to 8.4 in one step: The official MySQL manual does not support upgrades that skip an LTS series and tells you to go 5.7 → 8.0 → 8.4. So when migrating from 5.7, you cannot avoid dealing with the changes in 8.0.
WordPress recommendations: The requirements page on wordpress.org recommends MySQL 8.0 or later, or MariaDB 10.11 or later.
Distribution packages: The mysql-server package in Ubuntu 24.04's standard repository is in the 8.0 series (8.0.46). How it is supported depends on the distribution's policy.

Main changes from 5.7 to 8.0

What changes	What happens	What to do
The default authentication plugin becomes `caching_sha2_password`	Old client libraries cannot connect	Update the client. In our test, PHP 8.3's mysqli connected fine
The default character set becomes `utf8mb4` and the collation `utf8mb4_0900_ai_ci`	Loading a dump of tables created on 8.0 into MariaDB or 5.7 fails because the collation is unsupported	If you may need to go back, check the collations beforehand
`GRANT` can no longer create users	`GRANT … IDENTIFIED BY …` is a syntax error	Create the user first with `CREATE USER`, then use `GRANT` only to assign privileges
The query cache is removed	If the configuration file contains `query_cache_size` or similar, the server does not start	Delete those lines from the configuration file
The `NO_AUTO_CREATE_USER` flag of `sql_mode` is removed	If it is set in the configuration file, the server does not start	Remove it from `sql_mode`
More reserved words (such as `RANK`)	Queries that use columns or tables with those names without quoting fail	Quote the names with backticks in queries, or rename them

Features added in 8.0 include window functions, common table expressions (the WITH clause), roles, invisible indexes, descending indexes, JSON_TABLE() and a transactional data dictionary. WordPress core runs without using any of them, so during the migration, prioritize checking compatibility.

Step 1: Check in advance with the upgrade checker

The MySQL Shell upgrade checker lists anything that would get in the way of the migration. Specify the target version with --target-version, and use a MySQL Shell that is the same version as the target or newer (the highest version it can check is the MySQL Shell's own version).

# Check a 5.7 server for issues that would block an upgrade to 8.0.46
mysqlsh root@localhost:3306 -- util checkForServerUpgrade \
    --target-version=8.0.46 \
    --config-path=/etc/mysql/my.cnf

You will be prompted for the password. If you pass the configuration file with --config-path, it also checks for removed settings. In our test (MySQL Shell 8.4 run against 5.7.44), it showed a warning that a column named rank conflicts with a reserved word, and a notice that NO_AUTO_CREATE_USER in sql_mode would be cleared during the upgrade. Fix items marked "Error" before migrating, and read the items marked "Warning" to decide what to do.

Step 2: Take a backup

# Export only the WordPress database (the name is DB_NAME in wp-config.php)
mysqldump -u root -p --single-transaction --routines --triggers \
    --default-character-set=utf8mb4 wordpress > wordpress.sql

If WP-CLI is available, you can also export with wp db export wordpress.sql in the WordPress directory. If you are upgrading in place, also back up the entire data directory (copy it with the server stopped, or take a snapshot).

Step 3-A: Move to a new server (logical migration)

This method moves only the WordPress database to a newly prepared 8.0 or 8.4 server. Users and privileges are recreated on the new server. The official manual also describes exporting everything with --all-databases and loading it back, but that includes the system tables (the mysql database) and comes with caveats, such as not being loadable into a server with GTIDs enabled. If you are only moving WordPress, handling just its database is simpler.

-- Run on the new server (replace the names and password with your own)
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';

# Load the exported file
mysql -u root -p wordpress < wordpress.sql

The loaded tables are created with their original collation (for WordPress, something like utf8mb4_unicode_520_ci). Finally, change DB_HOST, DB_USER and DB_PASSWORD in wp-config.php to the new server's values.

Moving directly from 5.7 to 8.4 this way is not part of the official upgrade paths mentioned above. In our test, a WordPress database created on 5.7.44 loaded into 8.4 and could be read over a connection from PHP 8.3, but verify it in a staging environment before doing it in production.

Step 3-B: Upgrade on the same server (in-place migration)

This method swaps the packages on the same server. From MySQL 8.0.16 on, the new server automatically updates the data dictionary and system tables when it starts, so you no longer need to run mysql_upgrade by hand.

-- If innodb_fast_shutdown is 2, set it to 1 (fast) or 0 (slow) before stopping
SELECT @@innodb_fast_shutdown;
SET GLOBAL innodb_fast_shutdown = 0;

According to the official manual, shutting down with a fast or slow shutdown leaves the InnoDB files in a state that can handle file format differences between releases.

# Stop the server (the service is mysql or mysqld depending on your system)
sudo systemctl stop mysql

Then replace the packages with 8.0 ones, for example from the official MySQL APT / Yum repository, start the server, and check the error log (/var/log/mysql/error.log on Ubuntu) to confirm that the upgrade completed and that there are no errors preventing startup. How packages are replaced differs by source, so follow the official instructions of the repository you use.

Step 4: Verify after the migration

-- Check the version and the default character set
SELECT VERSION();
SHOW VARIABLES LIKE 'character_set_server';

-- Check each user's authentication plugin
SELECT user, host, plugin FROM mysql.user;

In the WordPress admin, you can see the version of the server you are connected to under "Database" on the "Info" tab of Tools → Site Health. Also try the features that write to the database, such as viewing and editing posts, logging in and contact forms.

Notes when moving from 8.0 to 8.4 LTS

mysql_native_password is disabled by default: In 8.4, this plugin is disabled even if it is loaded, and users with this plugin cannot log in. If the check in Step 4 shows users still on mysql_native_password, switch them before upgrading to 8.4.

ALTER USER 'wpuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'new-password';

Run the checker again: Set --target-version to the 8.4 version you are moving to and check the same way as in Step 1.
From 8.0 to 8.4, you can upgrade in place, by logical migration or by replication (the official upgrade paths).

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)