Upgrade MySQL 8.0 to 8.4 LTS: Complete Migration Guide

MySQL 8.0 reached end of life in April 2026, which means no more security patches for the version most Ubuntu servers are still running. The supported path forward is MySQL 8.4 LTS, the current long-term-support release (supported until 2032). This guide walks you through upgrading an existing MySQL 8.0 server to 8.4 LTS on Ubuntu 22.04 or 24.04 — with a full backup first, an in-place upgrade via the official MySQL APT repository, and fixes for the two breaking changes that catch everyone off guard.

What you will achieve: a running MySQL 8.4 LTS server with all your databases, users, and stored routines intact, verified and production-ready.

Prerequisites

• Ubuntu 22.04 or 24.04 server with MySQL 8.0 installed (from Ubuntu's apt or the MySQL APT repo)
• A user with sudo access and the MySQL root credentials
• At least 2x your database size in free disk space (the upgrade rewrites system tables)
• A maintenance window — plan for 15–45 minutes of downtime depending on data size
• Know which applications connect to this server, and which client libraries they use (old clients matter for Step 7)

Step 1 — Check your current version and server health

First, confirm what you are running and make sure the server is healthy before touching anything. An upgrade on top of a corrupt table is a bad day.

mysql -u root -p -e "SELECT VERSION();"

This prints your server version — expect something like 8.0.x. Next, run an upgrade-readiness check across all databases:

mysqlcheck -u root -p --all-databases --check-upgrade

mysqlcheck --check-upgrade flags tables that use features removed or changed in newer versions. Fix anything it reports before proceeding. Also glance at the error log for existing problems:

sudo tail -50 /var/log/mysql/error.log

Step 2 — Back up everything (twice if you can)

There is no supported in-place downgrade from 8.4 back to 8.0. Your backup is your rollback plan, so do not skip this.

sudo mkdir -p /backup
sudo mysqldump -u root -p --all-databases \
  --single-transaction --quick \
  --routines --events --triggers | \
  gzip > /backup/mysql-80-full-$(date +%F).sql.gz

--single-transaction takes a consistent snapshot of InnoDB tables without locking them; --routines --events --triggers includes stored procedures, events, and triggers that a plain dump would miss; gzip keeps the file small. Verify the backup is not empty:

ls -lh /backup/mysql-80-full-*.sql.gz
zcat /backup/mysql-80-full-*.sql.gz | head -20

You should see real CREATE TABLE statements. Also snapshot your configuration, because the upgrade can change defaults:

sudo cp -a /etc/mysql /etc/mysql.8.0.bak

Step 3 — Check for the two breaking changes in 8.4

MySQL 8.4 is mostly a drop-in upgrade, but two changes bite people:

1. mysql_native_password is disabled by default. Users still authenticating with the old plugin may fail to connect after the upgrade. List affected users now:

   mysql -u root -p -e "SELECT user, host, plugin FROM mysql.user;"

   Note every row showing mysql_native_password — you will migrate them in Step 7.

2. Removed server variables. 8.4 removes variables that were deprecated in 8.0, most notably default_authentication_plugin (replaced by authentication_policy) and expire_logs_days (replaced by binlog_expire_logs_seconds). If any of these sit in your my.cnf, the 8.4 server will refuse to start with an "unknown variable" error. Scan your config:

   sudo grep -rn "default_authentication_plugin\|expire_logs_days\|mysql_native_password" /etc/mysql/

   Comment out or replace every match before upgrading.

Step 4 — Point apt at the MySQL 8.4 repository

Ubuntu's own repositories still ship MySQL 8.0, so you need Oracle's official MySQL APT repository configured for the 8.4 series. Add the signing key:

curl -fsSL https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 | \
  sudo gpg --dearmor -o /usr/share/keyrings/mysql-apt.gpg

This downloads MySQL's package signing key and stores it in your keyring so apt can verify the packages. Now add the repository for your Ubuntu release:

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "deb [signed-by=/usr/share/keyrings/mysql-apt.gpg] \
  http://repo.mysql.com/apt/ubuntu/ $CODENAME mysql-8.4" | \
  sudo tee /etc/apt/sources.list.d/mysql-8-4.list

$VERSION_CODENAME resolves to jammy on 22.04 or noble on 24.04, so this works on both. Refresh the package lists:

sudo apt update

Confirm apt now sees 8.4 as the candidate version:

apt-cache policy mysql-server | head -10

You should see a 8.4.x candidate from repo.mysql.com.

Step 5 — Run the in-place upgrade

With the repository in place, a normal package upgrade moves you to 8.4. The installer stops the server, replaces the binaries, and — on first start — automatically upgrades the data dictionary and system tables (manual mysql_upgrade has not been needed since 8.0.16).

sudo apt install -y mysql-server

If apt says mysql-server is already the newest version, the 8.4 repo is not active — re-check Step 4, and make sure no hold is pinning the package:

sudo apt-mark showhold | grep -i mysql

Remove any hold with sudo apt-mark unhold mysql-server and retry.

Step 6 — Restart and confirm the upgrade completed

sudo systemctl restart mysql
sudo systemctl status mysql --no-pager

status should show active (running). Now verify the version and check the error log for the automatic upgrade messages:

mysql -u root -p -e "SELECT VERSION();"
sudo grep -i "upgrade" /var/log/mysql/error.log | tail -10

You are looking for 8.4.x from the version query and log lines confirming the data dictionary upgrade finished without errors.

Step 7 — Fix authentication for app users

This is the step most guides skip. If Step 3 found users on mysql_native_password, migrate them to the modern default plugin:

ALTER USER 'appuser'@'%' IDENTIFIED WITH caching_sha2_password BY 'your-strong-password';
FLUSH PRIVILEGES;

Repeat for every user from your Step 3 list, using each account's real password. Then test the actual application connection — not just the mysql client. If an old client library (very old PHP mysqlnd, ancient connectors) cannot speak caching_sha2_password, you have two options: upgrade the client library (preferred), or as a temporary measure re-enable the old plugin by adding this under [mysqld] in your config and restarting:

mysql_native_password=ON

Treat that as a stopgap while you modernize the client — do not leave it on permanently.

Step 8 — Post-upgrade health checks

Run the upgrade-readiness check again to confirm everything is clean on 8.4:

mysqlcheck -u root -p --all-databases --check-upgrade

Then verify the things your monitoring might not catch: scheduled backups still run (your mysqldump cron uses the new client), replication — if any — is flowing with SHOW REPLICA STATUS, and slow-query or audit plugins you rely on loaded correctly. Check the error log one final time for warnings:

sudo grep -i "warning\|error" /var/log/mysql/error.log | tail -20

Verify it worked

• mysql -u root -p -e "SELECT VERSION();" returns 8.4.x
• sudo systemctl is-active mysql returns active
• Your application connects and serves traffic normally
• mysqlcheck --all-databases reports no errors
• The error log shows no new warnings since the upgrade

Common issues & fixes

1. "Plugin 'mysql_native_password' is not loaded"

An app user still configured for the old plugin. Migrate the user with ALTER USER ... IDENTIFIED WITH caching_sha2_password (Step 7), or temporarily set mysql_native_password=ON.

2. Server fails to start: "unknown variable 'default_authentication_plugin=...'"

Your my.cnf references a variable removed in 8.4. Remove the line (or replace expire_logs_days with binlog_expire_logs_seconds) and restart with sudo systemctl restart mysql.

3. apt says mysql-server is already the newest version (still 8.0)

The 8.4 repository is not active. Re-run Step 4, confirm apt-cache policy mysql-server shows an 8.4 candidate from repo.mysql.com, and check for apt holds.

4. Data dictionary upgrade fails / server will not start after install

Usually disk space or a corrupt table. Check df -h and the error log. If the data directory is damaged, stop MySQL, restore your Step 2 backup onto a fresh 8.4 install with zcat /backup/mysql-80-full-*.sql.gz | mysql -u root -p, and investigate the original failure before retrying.

5. Application connects but queries behave differently

8.4 tightened a few defaults (notably around authentication and some removed variables). Diff your effective configuration against the backup: diff <(mysqld --verbose --help) ... is noisy — simpler: compare /etc/mysql.8.0.bak against /etc/mysql and review every setting you had customized.

---

You are now running MySQL 8.4 LTS with security support through 2032 — no more EOL anxiety, plus the performance and InnoDB improvements from four years of 8.0 point releases. Keep your Step 2 backup for a week or two until you are confident everything is stable.

Upgrading a production database with zero surprises takes planning: backups, rollback paths, and client compatibility testing. If you would rather have an expert handle it, XpertBees manages MySQL upgrades and server migrations for businesses — reach out and we will plan yours.