[{"data":1,"prerenderedAt":209},["ShallowReactive",2],{"seo-verification":3,"blog-mysql-8-0-eol-migration-vps-ma-fr":6,"promo-bar-likely":208},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-mysql-8-0-eol-migration-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":148,"ctaBody":149,"ctaButton":150,"ctaUrl":151,"relatedPosts":152},464,"mysql-8-0-eol-migration-vps",{"fr":10,"en":12,"ar":13,"es":14},"mysql-8-0-end-of-life-migration-vps","mysql-8-0-انتهاء-الدعم-ترقية-vps","mysql-8-0-fin-de-soporte-migracion-vps","Migration MySQL 8.0 vers 8.4 LTS sur VPS : guide complet","MySQL 8.0 EOL le 30 avril 2026 : plus aucun patch de sécurité. Migrez vers MySQL 8.4 LTS — breaking changes, prérequis, upgrade in-place et quand choisir MariaDB 11.x.",11,0,false,"2026-10-17T00:00:00+00:00","2026-11-08T01:13:14+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},6,"Bases de données","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmysql-8-0-eol-migration-vps-poster.svg","Le 30 avril 2026, Oracle a officiellement mis fin au support de MySQL 8.0 : aucun correctif de sécurité ne sera plus publié pour cette branche. Chaque CVE identifiée reste ouverte sur votre serveur, indéfiniment. MySQL 8.4, première version LTS de la série 8, prend le relais : Premier Support jusqu'en avril 2029, puis Extended Support jusqu'en avril 2032. Ce guide détaille les incompatibilités à connaître, les vérifications à effectuer avant la bascule, la procédure d'upgrade in-place sur un VPS Linux, et les cas concrets où MariaDB 11.x constitue une alternative plus pertinente.",[35,39,42,45,55,58,64,95,98,100,102,105,136,138,145],{"type":36,"title":37,"body":38},"h2","Pourquoi migrer maintenant : EOL et exposition aux CVE","La fin de vie officielle de MySQL 8.0 est fixée au 30 avril 2026 selon le calendrier Oracle Lifetime Support (oracle.com\u002Fsupport\u002Flifetime-support\u002F). À partir de cette date, Oracle ne publie plus de correctifs de sécurité pour la branche 8.0.x, quelle que soit la gravité d'une CVE. Les serveurs qui restent sur 8.0 accumulent donc une dette de sécurité qui grossit à chaque bulletin trimestriel d'Oracle — le CPU (Critical Patch Update) — sans jamais être comblée.",{"type":40,"body":41},"p","MySQL 8.4 est la première version désignée LTS dans l'histoire de MySQL. Selon la politique Lifetime Support d'Oracle, une série LTS reçoit cinq ans de Premier Support puis trois ans d'Extended Support : pour la 8.4, jusqu'en avril 2029 puis jusqu'en avril 2032 (dev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Fmysql-releases.html). Contrairement aux branches d'innovation 8.1, 8.2 et 8.3 — publiées entre 2023 et 2024, sans support prolongé — la 8.4 reçoit des correctifs de sécurité et des patches de stabilité sur la durée. Une deuxième série LTS, MySQL 9.7, est sortie en avril 2026, mais Oracle ne prend pas en charge le saut d'une série LTS : depuis la 8.0, la 8.4 est l'étape obligée, et la 9.7 se prépare ensuite à partir de la 8.4.",{"type":36,"title":43,"body":44},"Breaking changes à connaître avant la bascule","—",{"type":46,"items":47},"ul",[48,49,50,51,52,53,54],"**`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`\u002F`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`.",{"type":36,"title":56,"body":57},"Prérequis avant de commencer","Une migration de moteur de base de données en production ne s'improvise pas. Trois conditions doivent être réunies avant de lancer quoi que ce soit : un backup vérifié, la connaissance exacte de votre version actuelle, et une vérification de compatibilité de l'application.",{"type":46,"items":59},[60,61,62,63],"**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 `\u002Fvar`.",{"type":65,"title":66,"steps":67},"steps","Procédure de migration MySQL 8.0 → 8.4 LTS sur VPS",[68,71,74,77,80,83,86,89,92],{"title":69,"body":70},"Sauvegarde complète avec vérification","Exécutez `mysqldump --all-databases --single-transaction --routines --events --triggers > \u002Froot\u002Fbackup_mysql80_$(date +%Y%m%d).sql`. Vérifiez la fin du fichier avec `tail -5 \u002Froot\u002Fbackup_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.",{"title":72,"body":73},"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.",{"title":75,"body":76},"Vérification des variables dépréciées dans my.cnf","Ouvrez `\u002Fetc\u002Fmysql\u002Fmysql.conf.d\u002Fmysqld.cnf` (ou `\u002Fetc\u002Fmy.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.",{"title":78,"body":79},"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`.",{"title":81,"body":82},"Ajout du dépôt MySQL 8.4 et mise à jour des paquets","Sur Debian 12 \u002F Ubuntu 22.04 : téléchargez le paquet de configuration du dépôt officiel MySQL depuis `dev.mysql.com\u002Fdownloads\u002Frepo\u002Fapt\u002F` (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.",{"title":84,"body":85},"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).",{"title":87,"body":88},"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 (`\u002Fvar\u002Flog\u002Fmysql\u002Ferror.log`) et la présence des tables système : `SHOW DATABASES;` doit lister `sys`, `performance_schema` et `information_schema`.",{"title":90,"body":91},"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).",{"title":93,"body":94},"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.",{"type":36,"title":96,"body":97},"MariaDB 11.x : quand préférer cette alternative","MariaDB 11.x est un fork de MySQL qui a divergé significativement depuis la version 10.3. Il existe des cas précis où MariaDB 11.x est plus adapté qu'un upgrade vers MySQL 8.4, et des cas où il ne l'est pas.",{"type":40,"body":99},"**Préférez MariaDB 11.x si** votre application utilise des fonctionnalités propres à MariaDB déjà présentes dans votre stack (colonnes système, séquences, Spider engine, Galera Cluster natif) ; si vous avez besoin d'un cluster multi-maître sans la complexité de MySQL Group Replication ; ou si vous opérez sous contrainte de licence stricte et souhaitez rester sur un fork maintenu par la fondation MariaDB (GPLv2). MariaDB 11.4 LTS est maintenue jusqu'en mai 2029 et la 11.8 LTS jusqu'en juin 2028 ; une nouvelle série LTS, la 12.3, est sortie en mai 2026. MariaDB 11.x maintient `mysql_native_password` par défaut — ce qui simplifie la migration des applications héritées.",{"type":40,"body":101},"**Préférez MySQL 8.4 LTS si** votre application est développée et testée spécifiquement contre MySQL (ORM comme Laravel Eloquent ou Hibernate qui exploitent des fonctionnalités MySQL-spécifiques) ; si vous utilisez MySQL Enterprise pour des fonctions comme l'audit plugin ou le Thread Pool commercial ; ou si votre hébergeur ne propose que des sauvegardes optimisées pour MySQL (Percona XtraBackup). La migration de MySQL 8.0 vers MariaDB 11.x est une migration inter-moteurs, plus risquée et hors du périmètre de ce guide — elle mérite une procédure dédiée avec tests d'intégration complets.",{"type":103,"body":104},"tip","**Rollback possible dans les 24 heures** : si vous avez pris un snapshot VPS avant l'upgrade, la restauration ramène l'intégralité du serveur à l'état MySQL 8.0 en quelques minutes. Sans snapshot, un rollback depuis un dump SQL est possible mais plus long : créez un second VPS, restaurez le dump avec `mysql \u003C backup_mysql80_*.sql`, redirigez l'application, puis rétablissez l'ancien VPS. Ne supprimez le backup et le snapshot qu'après 72 heures de production stable sur MySQL 8.4.",{"type":106,"title":107,"headers":108,"rows":113},"comparison","MySQL 8.0 vs MySQL 8.4 LTS vs MariaDB 11.x",[109,110,111,112],"Critère","MySQL 8.0","MySQL 8.4 LTS","MariaDB 11.x",[114,119,124,128,132],[115,116,117,118],"Support sécurité","Terminé (30 avr. 2026)","Premier : avril 2029 · Extended : avril 2032","Jusqu'en 2029 (11.4 LTS)",[120,121,122,123],"mysql_native_password","Présent (déprécié)","Désactivé par défaut (supprimé en 9.0)","Présent par défaut",[125,126,126,127],"Cluster multi-maître","Group Replication","Galera Cluster natif",[129,130,130,131],"Compatibilité applications MySQL","Native","Majoritaire, quelques écarts",[133,134,134,135],"Licence","GPL + Enterprise commerciale","GPLv2 (MariaDB Foundation)",{"type":36,"title":137,"body":44},"Dépannage : erreurs courantes après la migration",{"type":46,"items":139},[140,141,142,143,144],"**`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 `\u002Fvar\u002Flog\u002Fmysql\u002Ferror.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`\u002F`MASTER` n'existent plus. Mettez à jour les requêtes de monitoring en vous appuyant sur les noms documentés dans `dev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Fperformance-schema.html`.",{"type":36,"title":146,"body":147},"Passer à MySQL 8.4 LTS : ce qu'il faut retenir","La migration de MySQL 8.0 vers MySQL 8.4 LTS est une upgrade in-place réalisable en moins d'une heure sur un VPS bien préparé. Les deux points d'arrêt les plus fréquents sont la désactivation par défaut de `mysql_native_password` — qui casse les connexions d'applications héritées si les comptes n'ont pas été migrés — et les variables système retirées dans `my.cnf`, qui empêchent le démarrage du service. Un audit préalable de ces deux points réduit le risque à presque zéro. Pour les stacks qui ont besoin de `mysql_native_password` ou d'un cluster multi-maître sans complexité de configuration, MariaDB 11.4 LTS est une alternative sérieuse, à condition de traiter la migration comme une opération distincte avec ses propres tests d'intégration.","Un VPS Linux pour votre base de données MySQL 8.4","Hébergez MySQL 8.4 LTS sur un VPS Linux managé, avec snapshots inclus pour sécuriser chaque migration.","Voir les offres VPS Linux","\u002Fvps-linux",[153,171,191],{"id":154,"slug":155,"slugs":156,"title":160,"excerpt":161,"readTime":162,"views":18,"isPinned":19,"noindex":19,"publishedAt":163,"updatedAt":164,"category":165,"categories":166,"featuredImage":30,"bgImage":31,"posterImage":168,"relatedSolution":169},57,"heberger-mysql-vps",{"fr":155,"en":157,"ar":158,"es":159},"hosting-mysql-on-a-vps","استضافة-mysql-على-خادم-vps","alojar-mysql-en-un-vps","Héberger MySQL sur un VPS : guide complet","Installez MySQL 8.4 LTS sur un VPS : prérequis, sécurisation, performances InnoDB, accès distant sécurisé, sauvegardes automatisées et dépannage.",9,"2026-04-24T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":25,"appSlug":170},"mysql-stack",{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":180,"views":181,"isPinned":19,"noindex":19,"publishedAt":182,"updatedAt":183,"category":184,"categories":185,"featuredImage":30,"bgImage":31,"posterImage":187,"relatedSolution":188},146,"heberger-mariadb-vps",{"fr":173,"en":175,"ar":176,"es":177},"mariadb-on-a-vps-free-fast-controlled-sql","mariadb-على-vps-sql-حر-وسريع-وتحت-السيطرة","alojar-mariadb-en-un-vps","MariaDB sur VPS : SQL libre, rapide et maîtrisé","Déployez MariaDB sur un VPS ServOrbit : installation 1 clic, sauvegardes automatisées, optimisation InnoDB et accès distant sécurisé.",10,1,"2026-01-30T00:00:00+00:00","2026-10-07T23:07:24+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[186],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mariadb-vps-poster.svg",{"categorySlug":189,"appSlug":190},"db","mariadb-stack",{"id":192,"slug":193,"slugs":194,"title":198,"excerpt":199,"readTime":200,"views":201,"isPinned":19,"noindex":19,"publishedAt":202,"updatedAt":203,"category":204,"categories":205,"featuredImage":30,"bgImage":31,"posterImage":207,"relatedSolution":30},225,"postgresql-fin-de-vie-planifier-montee-version",{"fr":193,"en":195,"ar":196,"es":197},"postgresql-end-of-life-plan-your-major-upgrade","postgresql-ونهاية-الدعم-تخطيط-الترقية-الكبرى","postgresql-fin-de-vida-planificar-actualizacion","PostgreSQL en fin de vie : planifier la montée de version","PostgreSQL suit chaque version majeure cinq ans, jusqu'à un arrêt en novembre. Repérez la vôtre et planifiez la montée sans perdre de données.",4,3,"2026-08-05T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[206],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpostgresql-fin-de-vie-planifier-montee-version-poster.svg",true,1794270757690]