Migration MySQL 8.0 vers 8.4 LTS sur VPS : guide complet

Pourquoi migrer maintenant : EOL et exposition aux CVE

Breaking changes à connaître avant la bascule

• mysql_native_password supprimé : le plugin d'authentification mysql_native_password est définitivement supprimé dans MySQL 8.4 (il était seulement déprécié en 8.0). Tout compte utilisateur qui s'appuie sur ce plugin provoquera une erreur de connexion immédiate après l'upgrade. Les applications PHP antérieures à PHP 8.1, WordPress sans PDO configuré correctement, et les clients JDBC anciens sont les cas les plus fréquents. La méthode de remplacement est caching_sha2_password, active par défaut depuis MySQL 8.0 mais ignorée par de nombreuses configurations héritées.
• Changement du paramètre authentication_policy : la valeur par défaut passe à caching_sha2_password, et toute ligne default_authentication_plugin dans my.cnf est désormais ignorée avec un avertissement. Si votre my.cnf définit encore ce paramètre, il doit être remplacé par authentication_policy.
• Suppression de pct dans CREATE TABLE … ROW_FORMAT=COMPRESSED : l'option KEY_BLOCK_SIZE et le paramètre innodb_file_format sont retirés. Les tables créées avec ROW_FORMAT=COMPRESSED fonctionnent encore, mais toute tentative de modifier innodb_file_format en runtime provoque une erreur. Vérifiez que vos scripts DDL n'utilisent plus cette variable.
• Évolution du type JSON : MySQL 8.4 renforce la conformité JSON/SQL. Les fonctions JSON_TABLE(), JSON_VALUE() et les chemins JSON avec des caractères Unicode mal formés peuvent se comporter différemment. Un dump de table contenant des colonnes JSON volumineuses doit être validé en environnement de test avant la bascule en production.
• Charset et collation par défaut : utf8mb4 et utf8mb4_0900_ai_ci restent les valeurs par défaut, mais MySQL 8.4 rejette plus strictement les colonnes déclarées en utf8 (alias de utf8mb3). Une migration de collation peut être nécessaire sur les bases historiques créées sous MySQL 5.7.
• Variables système supprimées ou renommées : plusieurs variables présentes dans 8.0 et marquées dépréciées sont supprimées en 8.4 — notamment innodb_undo_tablespaces (inutile depuis que les tablespaces undo sont toujours activés), slave_* (remplacées par replica_*), et query_cache_* (le query cache ayant été supprimé en 8.0). Un mysqlcheck renvoie les avertissements correspondants.
• Réplication : les noms de variables liées à la réplication ont définitivement basculé vers la terminologie source/replica. Tout script ou monitoring qui appelle encore SHOW SLAVE STATUS doit être mis à jour en SHOW REPLICA STATUS.

Prérequis avant de commencer

• Backup complet et testé : exécutez mysqldump --all-databases --single-transaction --routines --events > backup_pre_migration.sql et vérifiez que le fichier est lisible (taille cohérente, pas de message ERROR en fin de fichier). Une sauvegarde non vérifiée n'est pas une sauvegarde.
• Version actuelle et moteur de tables : lancez SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_version'; et listez les tables non-InnoDB avec SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine != 'InnoDB' AND table_schema NOT IN ('information_schema','performance_schema','mysql','sys');. Toute table MyISAM ou MEMORY doit être évaluée avant l'upgrade.
• Compatibilité applicative : identifiez le plugin d'authentification de chaque compte avec SELECT user, host, plugin FROM mysql.user;. Tout utilisateur en mysql_native_password doit être migré vers caching_sha2_password avant ou pendant l'upgrade.
• Espace disque disponible : une upgrade in-place sur Debian/Ubuntu peut temporairement doubler l'espace occupé par les ibdata. Vérifiez qu'il reste au moins 20 % d'espace libre sur la partition /var.

Procédure de migration MySQL 8.0 → 8.4 LTS sur VPS

1. 01

   Sauvegarde complète avec vérification

   Exécutez mysqldump --all-databases --single-transaction --routines --events --triggers > /root/backup_mysql80_$(date +%Y%m%d).sql. Vérifiez la fin du fichier avec tail -5 /root/backup_mysql80_*.sql : la dernière ligne doit être -- Dump completed on …. Stockez ce fichier hors du VPS (objet S3, NFS, copie locale) avant de continuer.

2. 02

   Audit des comptes et plugins d'authentification

   Lancez SELECT user, host, plugin FROM mysql.user ORDER BY plugin;. Pour chaque utilisateur en mysql_native_password, exécutez ALTER USER 'nom'@'hôte' IDENTIFIED WITH caching_sha2_password BY 'mot_de_passe';. Mettez à jour la chaîne de connexion de chaque application concernée (DSN PHP, fichier .env Laravel, configuration WordPress) avant l'upgrade.

3. 03

   Vérification des variables dépréciées dans my.cnf

   Ouvrez /etc/mysql/mysql.conf.d/mysqld.cnf (ou /etc/my.cnf selon la distribution) et supprimez ou remplacez : default_authentication_plugin → authentication_policy = caching_sha2_password, slave_* → replica_*, innodb_undo_tablespaces, query_cache_size, query_cache_type. Toute variable inconnue bloque le démarrage de MySQL 8.4.

4. 04

   Arrêt propre du service et snapshot

   Sur un VPS Proxmox ou KVM, prenez un snapshot avant de toucher aux paquets : contactez votre panneau de contrôle ou utilisez l'API de votre hébergeur. Ensuite : systemctl stop mysql puis vérifiez que le service est bien arrêté avec systemctl status mysql.

5. 05

   Ajout du dépôt MySQL 8.4 et mise à jour des paquets

   Sur Debian 12 / Ubuntu 22.04 : téléchargez le paquet de configuration du dépôt officiel MySQL depuis dev.mysql.com/downloads/repo/apt/ (choisissez le .deb correspondant à votre distribution), installez-le avec dpkg -i mysql-apt-config_*.deb, sélectionnez MySQL 8.4 LTS dans le menu, puis exécutez apt-get update && apt-get install mysql-server. Le gestionnaire de paquets remplace le binaire 8.0 par le binaire 8.4 et déclenche la mise à niveau des fichiers système MySQL automatiquement.

6. 06

   Upgrade des tables système

   Au premier démarrage de MySQL 8.4, le moteur met à jour les tables système automatiquement. Vérifiez dans les logs : journalctl -u mysql -n 50 | grep -i 'upgrade\|error'. Si l'upgrade automatique n'a pas tourné (cas rare avec certaines distributions), lancez manuellement mysql_upgrade --user=root --password.

7. 07

   Vérification post-upgrade

   Connectez-vous et vérifiez la version : SELECT VERSION(); doit renvoyer 8.4.x. Lancez ensuite mysqlcheck --all-databases --auto-repair --user=root --password pour détecter d'éventuelles corruptions de tables. Vérifiez les logs d'erreur (/var/log/mysql/error.log) et la présence des tables système : SHOW DATABASES; doit lister sys, performance_schema et information_schema.

8. 08

   Test fonctionnel de l'application

   Relancez votre application et vérifiez les points sensibles : connexion à la base, authentification utilisateur, requêtes sur colonnes JSON, procédures stockées. Sur une application PHP, activez temporairement l'affichage des erreurs ou consultez les logs applicatifs. Une erreur The server requested authentication method unknown to the client indique qu'un compte est encore en mysql_native_password non migré.

9. 09

   Nettoyage et activation de la surveillance

   Supprimez le fichier de backup local une fois la copie hors-VPS confirmée. Vérifiez votre outil de monitoring (Prometheus mysqld_exporter, Netdata, Zabbix) : certaines métriques ont changé de nom entre 8.0 et 8.4, notamment celles liées à la réplication. Programmez une vérification des logs d'erreur MySQL à 24 h et 72 h post-migration.

MariaDB 11.x : quand préférer cette alternative

MySQL 8.0 vs MySQL 8.4 LTS vs MariaDB 11.x

Faites défiler le tableau

Dépannage : erreurs courantes après la migration

• ERROR 1045 (28000): Access denied après upgrade : vérifiez le plugin d'authentification du compte avec SELECT plugin FROM mysql.user WHERE user='nom';. S'il est encore mysql_native_password, l'upgrade n'a pas migré ce compte — réexécutez ALTER USER … IDENTIFIED WITH caching_sha2_password BY '…';.
• Unknown system variable 'default_authentication_plugin' : cette variable n'est plus reconnue en 8.4. Retirez-la de my.cnf et remplacez par authentication_policy = caching_sha2_password si vous souhaitez forcer ce mécanisme globalement.
• MySQL ne démarre plus après upgrade : consultez /var/log/mysql/error.log. L'erreur la plus fréquente est une variable système inconnue dans my.cnf. Commentez les variables une par une jusqu'à identifier la source, puis corrigez.
• Performances dégradées sur requêtes de tri : MySQL 8.4 applique plus strictement l'ordre des index sur certaines requêtes. Lancez EXPLAIN sur les requêtes lentes et vérifiez que les index couvrants sont toujours utilisés. Un ANALYZE TABLE nom_table; force la mise à jour des statistiques.
• Table 'performance_schema.replication_applier_status' introuvable dans les scripts de monitoring : certains tableaux de la performance_schema ont été renommés ou réorganisés. Mettez à jour les requêtes de monitoring pour utiliser les nouveaux noms de vues documentés dans dev.mysql.com/doc/refman/8.4/en/performance-schema.html.

Passer à MySQL 8.4 LTS : ce qu'il faut retenir