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 removed: the mysql_native_password authentication plugin is permanently removed in MySQL 8.4 (it was only deprecated in 8.0). Any user account relying on this plugin will fail to connect immediately after the upgrade. PHP applications older than PHP 8.1, 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 becomes caching_sha2_password, and any default_authentication_plugin line in my.cnf is now silently ignored. If your my.cnf still defines this parameter, replace it with authentication_policy.
• Removal of innodb_file_format and related options: the innodb_file_format variable is removed. Tables created with ROW_FORMAT=COMPRESSED still work, but any attempt to set innodb_file_format at runtime produces an error. Verify that your DDL scripts no longer reference this variable.
• JSON type changes: MySQL 8.4 strengthens JSON/SQL conformance. Functions like JSON_TABLE() and JSON_VALUE(), and JSON paths with malformed Unicode characters, may behave differently. 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, but MySQL 8.4 more strictly rejects columns declared as utf8 (alias for utf8mb3). A collation migration may be required for historical databases created under MySQL 5.7.
• Removed or renamed system variables: several variables present in 8.0 and marked deprecated are removed in 8.4 — notably innodb_undo_tablespaces, slave_* (replaced by replica_*), and query_cache_* (the query cache was removed in 8.0). A mysqlcheck run reports relevant warnings.
• Replication: replication-related variable names have definitively switched to source/replica terminology. Any script or monitoring tool still calling SHOW SLAVE STATUS must be updated to SHOW REPLICA 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: an in-place upgrade on Debian/Ubuntu may temporarily double the space used by ibdata files. 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, slave_* → replica_*, innodb_undo_tablespaces, query_cache_size, query_cache_type. 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), run manually mysql_upgrade --user=root --password.

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 error The server requested authentication method unknown to the client means an account is still on unmigrated mysql_native_password.

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, the upgrade did not migrate this account — rerun 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 applies index ordering more strictly on some queries. Run EXPLAIN on slow queries and verify that covering indexes are still used. ANALYZE TABLE table_name; forces a statistics refresh.
• performance_schema.replication_applier_status table not found in monitoring scripts: some performance_schema tables were renamed or reorganized. Update monitoring queries to use the new view names documented at dev.mysql.com/doc/refman/8.4/en/performance-schema.html.

Moving to MySQL 8.4 LTS: key takeaways