[{"data":1,"prerenderedAt":204},["ShallowReactive",2],{"seo-verification":3,"blog-mysql-8-0-eol-migration-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-mysql-8-0-eol-migration-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":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.",10,0,false,"2026-10-17T00:00:00+00:00","2026-10-18T21:57:56+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 avec un support garanti jusqu'en avril 2032 — six ans de correctifs planifiés. 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. Oracle en garantit le support jusqu'en avril 2032 (dev.mysql.com\u002Fdoc\u002Frelnotes\u002Fmysql\u002F8.4\u002F). 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. Pour une base de données en production sur VPS, c'est la seule branche MySQL qui offre un horizon de planification sérieux.",{"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` 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\u002FSQL. 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`\u002F`replica`. Tout script ou monitoring qui appelle encore `SHOW SLAVE STATUS` doit être mis à jour en `SHOW REPLICA 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** : une upgrade in-place sur Debian\u002FUbuntu peut temporairement doubler l'espace occupé par les ibdata. 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`, `slave_*` → `replica_*`, `innodb_undo_tablespaces`, `query_cache_size`, `query_cache_type`. 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), lancez manuellement `mysql_upgrade --user=root --password`.",{"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. Une erreur `The server requested authentication method unknown to the client` indique qu'un compte est encore en `mysql_native_password` non migré.",{"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 (LGPL). MariaDB 11.4 LTS est la branche stable actuelle avec support jusqu'en 2029, et 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)","Jusqu'en avril 2032","Jusqu'en 2029 (11.4 LTS)",[120,121,122,123],"mysql_native_password","Présent (déprécié)","Supprimé","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","LGPL (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`, 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 `\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** : 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\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 suppression 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,189],{"id":154,"slug":155,"slugs":156,"title":160,"excerpt":161,"readTime":162,"views":18,"isPinned":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-09-17T14:09:38+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":17,"views":18,"isPinned":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},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é.","2026-01-30T00:00:00+00:00","2026-10-07T23:07:24+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mariadb-vps-poster.svg",{"categorySlug":187,"appSlug":188},"db","mariadb-stack",{"id":190,"slug":191,"slugs":192,"title":196,"excerpt":197,"readTime":198,"views":18,"isPinned":19,"publishedAt":199,"updatedAt":21,"category":200,"categories":201,"featuredImage":30,"bgImage":31,"posterImage":203,"relatedSolution":30},461,"postgresql-migrer-cloud-vers-self-hosted-vps",{"fr":191,"en":193,"ar":194,"es":195},"migrate-postgresql-from-rds-cloud-sql-supabase-to-vps","نقل-postgresql-من-rds-و-cloud-sql-و-supabase-إلى-vps","migrar-postgresql-de-rds-cloud-sql-o-supabase-a-un-vps","Migrer PostgreSQL depuis RDS, Cloud SQL ou un BaaS vers un VPS","Migration PostgreSQL depuis RDS, Cloud SQL et Supabase vers un VPS self-hosted : commandes exactes, pièges propres à chaque source et bascule sans downtime.",13,"2026-10-16T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[202],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpostgresql-migrer-cloud-vers-self-hosted-vps-poster.svg",1792361027372]