MySQL 8.0 to 8.4 LTS migration on a VPS: step-by-step guide

Why migrate now: EOL and CVE exposure

Breaking changes to know before upgrading

• mysql_native_password disabled: the mysql_native_password authentication plugin, deprecated since MySQL 8.0.34, is no longer loaded by default in MySQL 8.4 (it is removed in 9.0). You can temporarily re-enable it with mysql_native_password=ON in the [mysqld] section while you migrate the accounts. Any user account relying on this plugin will fail to connect immediately after the upgrade. PHP applications older than PHP 7.4, WordPress without PDO configured properly, and legacy JDBC clients are the most common cases. The replacement is caching_sha2_password, the default since MySQL 8.0 but bypassed by many legacy configurations.
• authentication_policy parameter change: the default_authentication_plugin variable, deprecated since 8.0.27, is removed in 8.4: a leftover line in my.cnf prevents the server from starting. authentication_policy replaces it; its default value (*,,) already uses caching_sha2_password for the first factor. If your my.cnf still defines this parameter, replace it with authentication_policy.
• Removed server options: expire_logs_days (replaced by binlog_expire_logs_seconds), --skip-host-cache (replaced by host_cache_size = 0), --ssl and --admin-ssl (replaced by --tls-version and --admin-tls-version), binlog_transaction_dependency_tracking, avoid_temporal_upgrade and show_old_temporals no longer exist in 8.4: setting them, at runtime or in my.cnf, produces an error. Verify that your configuration files and scripts no longer use these options.
• JSON columns: as with any major version upgrade, queries that rely on JSON_TABLE(), JSON_VALUE() or complex JSON paths must be replayed before the switch. Validate tables with large JSON columns in a test environment before switching to production.
• Charset and collation: utf8mb4 and utf8mb4_0900_ai_ci remain the defaults, and the utf8mb3 character set (of which utf8 is the alias) is deprecated: it remains accepted for the whole 8.4 series, but Oracle announces its removal in a future major release. Plan a migration to utf8mb4 for historical databases created under MySQL 5.7.
• Removed or renamed system variables: several replication options deprecated in 8.0 are removed in 8.4 — notably master_info_repository and relay_log_info_repository (only the crash-safe metadata tables remain), slave_rows_search_algorithms and log_bin_use_v1_events; the remaining slave_* variables are deprecated in favor of replica_*, and the query_cache_* variables were already gone in 8.0 along with the query cache. MySQL Shell's Upgrade Checker (util.checkForServerUpgrade()) flags these points before the switch.
• Replication: replication-related variable names have definitively switched to source/replica terminology. The old statements are removed in 8.4: any script or monitoring tool still calling SHOW SLAVE STATUS must be updated to SHOW REPLICA STATUS, as must START SLAVE → START REPLICA, CHANGE MASTER TO → CHANGE REPLICATION SOURCE TO and SHOW MASTER STATUS → SHOW BINARY LOG STATUS.

Prerequisites before starting

• Complete and verified backup: run mysqldump --all-databases --single-transaction --routines --events > backup_pre_migration.sql and verify the file is readable (consistent size, no ERROR message at the end of the file). An unverified backup is not a backup.
• Current version and table engines: run SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_version'; and list non-InnoDB tables with SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine != 'InnoDB' AND table_schema NOT IN ('information_schema','performance_schema','mysql','sys');. Any MyISAM or MEMORY table must be evaluated before the upgrade.
• Application compatibility: identify the authentication plugin for each account with SELECT user, host, plugin FROM mysql.user;. Any user on mysql_native_password must be migrated to caching_sha2_password before or during the upgrade.
• Available disk space: the backup dump and the data dictionary upgrade take up space on the server's disk. Verify at least 20% free space on the /var partition.

MySQL 8.0 → 8.4 LTS migration procedure on a VPS

1. 01

   Full backup with verification

   Run mysqldump --all-databases --single-transaction --routines --events --triggers > /root/backup_mysql80_$(date +%Y%m%d).sql. Verify the end of the file with tail -5 /root/backup_mysql80_*.sql: the last line should be -- Dump completed on …. Store this file off the VPS (S3 object storage, NFS, local copy) before proceeding.

2. 02

   Audit accounts and authentication plugins

   Run SELECT user, host, plugin FROM mysql.user ORDER BY plugin;. For each user on mysql_native_password, execute ALTER USER 'name'@'host' IDENTIFIED WITH caching_sha2_password BY 'password';. Update the connection string of each affected application (PHP DSN, Laravel .env, WordPress configuration) before the upgrade.

3. 03

   Check deprecated variables in my.cnf

   Open /etc/mysql/mysql.conf.d/mysqld.cnf (or /etc/my.cnf depending on your distribution) and remove or replace: default_authentication_plugin → authentication_policy = caching_sha2_password, expire_logs_days → binlog_expire_logs_seconds, skip-host-cache → host_cache_size = 0, slave_* → replica_*, master_info_repository, relay_log_info_repository. Any unknown variable blocks MySQL 8.4 from starting.

4. 04

   Clean service stop and snapshot

   On a Proxmox or KVM VPS, take a snapshot before touching packages: use your control panel or your hosting provider's API. Then: systemctl stop mysql and verify the service is stopped with systemctl status mysql.

5. 05

   Add the MySQL 8.4 repository and update packages

   On Debian 12 / Ubuntu 22.04: download the MySQL repository configuration package from dev.mysql.com/downloads/repo/apt/ (select the .deb for your distribution), install it with dpkg -i mysql-apt-config_*.deb, select MySQL 8.4 LTS in the menu, then run apt-get update && apt-get install mysql-server. The package manager replaces the 8.0 binary with the 8.4 binary and automatically upgrades MySQL system files.

6. 06

   Upgrade system tables

   On first startup of MySQL 8.4, the engine updates system tables automatically. Check the logs: journalctl -u mysql -n 50 | grep -i 'upgrade\|error'. If the automatic upgrade did not run (rare with some distributions), do not look for mysql_upgrade: the tool is removed in 8.4. Restart the server once with the --upgrade=FORCE option (for example upgrade = FORCE in the [mysqld] section, removed afterwards).

7. 07

   Post-upgrade verification

   Connect and verify the version: SELECT VERSION(); should return 8.4.x. Then run mysqlcheck --all-databases --auto-repair --user=root --password to detect any table corruption. Check the error log (/var/log/mysql/error.log) and the presence of system databases: SHOW DATABASES; should list sys, performance_schema and information_schema.

8. 08

   Application functional testing

   Restart your application and check sensitive points: database connection, user authentication, queries on JSON columns, stored procedures. On a PHP application, temporarily enable error display or check application logs. An account left on unmigrated mysql_native_password fails with ERROR 1045 (28000): Access denied and leaves a trace in the server log; the error The server requested authentication method unknown to the client instead points to a client too old for caching_sha2_password (PHP older than 7.4, for example).

9. 09

   Cleanup and monitoring activation

   Delete the local backup file once the off-VPS copy is confirmed. Check your monitoring tool (Prometheus mysqld_exporter, Netdata, Zabbix): some metric names changed between 8.0 and 8.4, especially replication-related ones. Schedule an error log check at 24h and 72h post-migration.

MariaDB 11.x: when to prefer this alternative

MySQL 8.0 vs MySQL 8.4 LTS vs MariaDB 11.x

Scroll the table

Troubleshooting: common errors after migration

• ERROR 1045 (28000): Access denied after upgrade: check the account's authentication plugin with SELECT plugin FROM mysql.user WHERE user='name';. If it is still mysql_native_password, this account was not migrated (the upgrade never changes an account's plugin) — run ALTER USER … IDENTIFIED WITH caching_sha2_password BY '…';.
• Unknown system variable 'default_authentication_plugin': this variable is no longer recognized in 8.4. Remove it from my.cnf and replace with authentication_policy = caching_sha2_password if you want to enforce this globally.
• MySQL does not start after upgrade: check /var/log/mysql/error.log. The most common error is an unknown system variable in my.cnf. Comment out variables one by one until the source is identified, then fix it.
• Degraded performance on sort queries: MySQL 8.4's optimizer may choose different execution plans than 8.0 on some queries. Run EXPLAIN on slow queries and verify that covering indexes are still used. ANALYZE TABLE table_name; forces a statistics refresh.
• Monitoring scripts failing after the upgrade: the Com_slave_* and Com_show_master_status counters are removed in 8.4 in favor of Com_replica_* and Com_show_binary_log_status, and the SLAVE/MASTER statements no longer exist. Update monitoring queries using the names documented at dev.mysql.com/doc/refman/8.4/en/performance-schema.html.

Moving to MySQL 8.4 LTS: key takeaways