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 désactivé : le plugin d'authentification mysql_native_password, déprécié depuis MySQL 8.0.34, n'est plus chargé par défaut dans MySQL 8.4 (il est supprimé en 9.0). On peut le réactiver temporairement avec mysql_native_password=ON dans la section [mysqld], le temps de migrer les comptes. 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 7.4, 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 variable default_authentication_plugin, dépréciée depuis 8.0.27, est supprimée en 8.4 : une ligne restée dans my.cnf empêche le démarrage du serveur. authentication_policy la remplace ; sa valeur par défaut (*,,) utilise déjà caching_sha2_password pour le premier facteur. Si votre my.cnf définit encore ce paramètre, il doit être remplacé par authentication_policy.
• Options serveur supprimées : expire_logs_days (remplacée par binlog_expire_logs_seconds), --skip-host-cache (remplacée par host_cache_size = 0), --ssl et --admin-ssl (remplacées par --tls-version et --admin-tls-version), binlog_transaction_dependency_tracking, avoid_temporal_upgrade et show_old_temporals n'existent plus en 8.4 : les définir, en runtime comme dans my.cnf, provoque une erreur. Vérifiez que vos fichiers de configuration et vos scripts n'utilisent plus ces options.
• Colonnes JSON : comme pour toute montée de version majeure, les requêtes qui reposent sur JSON_TABLE(), JSON_VALUE() ou des chemins JSON complexes doivent être rejouées avant la bascule. 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, et le jeu utf8mb3 (dont utf8 est l'alias) est déprécié : il reste accepté pendant toute la série 8.4, mais Oracle annonce sa suppression dans une version majeure future. Une migration vers utf8mb4 est à planifier sur les bases historiques créées sous MySQL 5.7.
• Variables système supprimées ou renommées : plusieurs options de réplication dépréciées en 8.0 sont supprimées en 8.4 — notamment master_info_repository et relay_log_info_repository (seules les tables de métadonnées, résistantes aux pannes, subsistent), slave_rows_search_algorithms et log_bin_use_v1_events ; les variables slave_* restantes sont dépréciées au profit de replica_*, et les variables query_cache_* ont disparu dès la 8.0 avec le query cache. L'Upgrade Checker de MySQL Shell (util.checkForServerUpgrade()) signale ces points avant la bascule.
• Réplication : les noms de variables liées à la réplication ont définitivement basculé vers la terminologie source/replica. Les anciennes instructions sont supprimées en 8.4 : tout script ou monitoring qui appelle encore SHOW SLAVE STATUS doit être mis à jour en SHOW REPLICA STATUS, de même que START SLAVE → START REPLICA, CHANGE MASTER TO → CHANGE REPLICATION SOURCE TO et SHOW MASTER STATUS → SHOW BINARY LOG 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 : le dump de sauvegarde et la mise à niveau du dictionnaire de données occupent de la place sur le disque du serveur. 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, expire_logs_days → binlog_expire_logs_seconds, skip-host-cache → host_cache_size = 0, slave_* → replica_*, master_info_repository, relay_log_info_repository. 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), ne cherchez pas mysql_upgrade : l'outil est supprimé en 8.4. Redémarrez le serveur une fois avec l'option --upgrade=FORCE (par exemple upgrade = FORCE dans la section [mysqld], à retirer ensuite).

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. Un compte resté en mysql_native_password non migré échoue avec ERROR 1045 (28000): Access denied et laisse une trace dans le journal du serveur ; l'erreur The server requested authentication method unknown to the client signale au contraire un client trop ancien pour caching_sha2_password (PHP antérieur à 7.4, par exemple).

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, ce compte n'a pas été migré (l'upgrade ne change le plugin d'aucun compte) — 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 : l'optimiseur de MySQL 8.4 peut choisir des plans d'exécution différents de ceux de la 8.0 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.
• Scripts de monitoring en erreur après l'upgrade : les compteurs Com_slave_* et Com_show_master_status sont supprimés en 8.4 au profit de Com_replica_* et Com_show_binary_log_status, et les instructions en SLAVE/MASTER n'existent plus. Mettez à jour les requêtes de monitoring en vous appuyant sur les noms documentés dans dev.mysql.com/doc/refman/8.4/en/performance-schema.html.

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