MySQL Fin de vie (EOL) : Pourquoi vous devez vérifier votre version immédiatement

1. Que signifie la fin de vie (EOL) de MySQL ? Pourquoi vous devez vérifier immédiatement

Qu’est-ce que l’EOL de MySQL ? Une explication depuis les bases

MySQL est un système de gestion de base de données relationnelle open‑source largement utilisé, déployé dans les applications web et les systèmes d’entreprise à travers le monde. Cependant, toutes les versions ne sont pas supportées indéfiniment.

MySQL a également un événement appelé « End of Life (EOL) ». Cela indique la date à laquelle son développeur (Oracle Corporation) met fin au support, tel que les mises à jour de sécurité et les corrections de bugs, pour cette version.

Par exemple, MySQL 5.7 a atteint la fin du support en octobre 2023. Des informations EOL comme celle‑ci sont cruciales car elles affectent directement la sécurité et la viabilité future de vos systèmes.

Le danger de « Je ne me suis pas rendu compte que c’était EOL »

De nombreux développeurs et ingénieurs d’exploitation sont prudents quant à la mise à niveau de MySQL. Ils peuvent penser « C’est stable, nous le laisserons tel quel », mais continuer à utiliser une version qui a atteint l’EOL comporte un risque important.

Plus précisément, les risques suivants s’appliquent :

• Les vulnérabilités de sécurité ne sont plus corrigées
• La compatibilité avec le système d’exploitation ou d’autres logiciels est perdue
• Le support des fournisseurs devient indisponible
• Les nouveaux développeurs peuvent éviter de travailler avec, augmentant les coûts de maintenance

Pour éviter ces risques, il est essentiel de vérifier régulièrement quelle version de MySQL votre entreprise utilise et si cette version est toujours supportée.

Connaître les informations de support prévient les « incidents »

Surtout pour les entreprises utilisant MySQL dans des systèmes critiques, la situation de « nous avons dépassé l’EOL sans le remarquer » peut entraîner de graves incidents ou des violations de sécurité plus tard.

Par conséquent, connaître le cycle de vie du support de votre version MySQL et planifier une mise à niveau ou une migration avant l’EOL est essentiel pour des opérations continues stables.

La section suivante indique quelles versions ont atteint l’EOL et quand.

2. Résumé de la fin du support des versions MySQL (Informations EOL)

Connaître les principales versions MySQL et leurs dates d’EOL

MySQL a connu des mises à jour de version continues pendant de nombreuses années, chacune avec des périodes de support définies. Voici une liste des versions majeures et de leur EOL (date de fin de vie) officiellement annoncée.

[Version-by-Version EOL Table]

※Les dates sont basées sur des informations publiques d’Oracle et de divers fournisseurs de services cloud.

MySQL 5.5 (Fin du support en 2018)

MySQL 5.5 a été publié en 2010 et adopté par de nombreuses applications web. Cependant, il a atteint la fin du support le 3 décembre 2018. Aucun correctif de sécurité ou de bug n’est plus fourni, donc s’il est toujours utilisé, une migration immédiate est requise.

MySQL 5.6 (Fin du support en 2021)

MySQL 5.6 a gagné en popularité grâce à une meilleure performance et des fonctionnalités ajoutées, mais il a atteint l’EOL le 5 février 2021. Si votre environnement utilise cette version, elle est désormais non supportée et très à risque.

MySQL 5.7 (Fin du support en octobre 2023)

MySQL 5.7 a été utilisé par de nombreux systèmes d’entreprise pendant des années, mais il a atteint la fin du support le 21 octobre 2023. De nombreux systèmes utilisent encore cette version, et le nombre d’entreprises migrantes augmente. L’attention se tourne désormais vers la vérification de la compatibilité et la migration des données.

MySQL 8.0 (Fin du support premier en avril 2025)**

MySQL 8.0 est la version stable actuelle, mais son support premier est prévu pour se terminer en avril 2025. Après cela, un support prolongé ou une migration vers l’édition LTS est recommandé. La nouvelle MySQL 8.4 LTS (sortie en 2024) reçoit l’attention pour des opérations stables à long terme.

Planifier à l’avance nécessite des informations EOL

Comme indiqué, chaque version MySQL a un EOL clairement défini, et une migration planifiée est requise. Vérifiez la version utilisée dans vos systèmes et changez votre état d’esprit de « c’est toujours correct » à « quand allons‑nous migrer ? ».

3. Que se passe‑t‑il lorsque le support se termine ? Risques liés à l’EOL

Utiliser une version après la fin du support comporte un risque très élevé

Lorsqu’une version de MySQL atteint la fin de vie (EOL), tout le support officiel — tel que mises à jour de sécurité, corrections de bugs et améliorations de fonctionnalités — est complètement interrompu. Cela signifie qu’il n’y a plus de support de la part d’Oracle.

Même si elle semble fonctionner normalement, des risques sérieux se cachent sous la surface. Surtout pour les serveurs web connectés à Internet ou les systèmes métiers essentiels, ces risques ne peuvent pas être ignorés.

Vulnérabilités de sécurité négligées

Le risque le plus critique est que les vulnérabilités nouvellement découvertes ne seront pas corrigées. Les attaquants ciblent souvent les versions EOL en se basant sur des failles déjà connues.

Et comme MySQL est si largement utilisé, il devient une cible particulièrement attractive. Après l’EOL, toute vulnérabilité découverte reste non corrigée et les défenses sont extrêmement limitées.

🔒 Pas de mitigation = Un état toujours ciblé.

Risque de violation des réglementations ou des normes de sécurité

Dans les entreprises et les organisations publiques, la conformité aux normes de sécurité de l’information telles que ISMS ou PCI DSS est de plus en plus exigée. Ces normes interdisent généralement l’utilisation de logiciels dont le support est terminé.

En d’autres termes, l’utilisation d’une version EOL de MySQL pourrait entraîner des constats d’audit ou nuire à la confiance des partenaires.

Problèmes d’incompatibilité avec le système d’exploitation ou d’autres logiciels

Une version EOL manque souvent de compatibilité vérifiée avec le système d’exploitation actuel ou d’autres logiciels, ce qui peut provoquer des dysfonctionnements inattendus ou une dégradation des performances. Par exemple, après une mise à jour du système d’exploitation, MySQL peut ne pas démarrer ou ses performances peuvent chuter de façon importante.

Cela peut entraîner des efforts de remédiation urgents ou, dans le pire des cas, des interruptions de service.

Accumulation de la dette technique

Maintenir une version après l’EOL signifie accumuler de la dette technique. Lorsqu’il devient nécessaire de mettre à niveau, les coûts de migration augmentent et les dépendances obsolètes se multiplient.

Le résultat est que plus vous retardez, plus les coûts et les risques augmentent.

Comment opérer en toute sécurité

Pour éviter les risques liés à l’EOL, vous n’êtes pas obligé de mettre à niveau immédiatement — mais il est important de planifier votre migration. Comprenez l’état actuel de votre version MySQL, prenez en compte le temps restant jusqu’à l’EOL et évaluez votre destination de migration pour préparer un environnement stable.

La section suivante présente les options que vous pouvez choisir comme destinations de migration, en montrant leurs fonctionnalités et les cas d’utilisation recommandés.

4. Options de migration : choisir la meilleure stratégie selon l’objectif

La clé de la gestion de l’EOL est une « stratégie de migration »

À l’approche de l’EOL de MySQL, la décision la plus importante est « où migrer ». Il ne suffit pas de simplement mettre à niveau ; vous devez choisir une option qui correspond à vos exigences système et à votre structure opérationnelle.

Nous présentons ici trois principaux schémas de migration, ainsi que leurs caractéristiques et leurs utilisateurs cibles.

Passer à MySQL 8.0 ou 8.4 LTS (Conservateur & axé sur la stabilité)

Le choix le plus simple est de passer à une version plus récente de MySQL. Actuellement, MySQL 8.0 est la norme, et l’attention se tourne vers MySQL 8.4 LTS (édition à support à long terme) à partir de 2024.

• Avantages :
• Haute compatibilité avec les environnements MySQL existants
• Poursuite de l’utilisation en open source
• Les outils existants tels que MySQL Workbench restent utilisables
• Inconvénients :
• Certains changements de syntaxe ou de spécifications peuvent provoquer des erreurs de compatibilité
• Les moteurs de stockage ou les jeux de caractères peuvent nécessiter une attention particulière
• Meilleure utilisation pour :
• Les PME ou les développeurs qui souhaitent maintenir des opérations stables sans changements majeurs du système

Migrer vers un SGBDR alternatif (MariaDB / TiDB) (Flexibilité & pérennité)

La migration vers un SGBDR compatible MySQL est également une forte option. Les plus populaires sont MariaDB et TiDB.

• MariaDB :
• Un fork de MySQL avec une syntaxe et une administration similaires
• Développement actif dirigé par sa communauté
• Riche en fonctionnalités d’optimisation des performances
• TiDB :
• Une base de données SQL distribuée cloud-native
• Excellente pour la haute disponibilité et l’évolutivité
• Forte pour les charges de travail analytiques (OLAP) et transactionnelles (OLTP)
• Le mieux adapté à :
• Les entreprises planifiant un traitement de données à grande échelle ou une migration vers le cloud
• Les équipes techniquement avancées souhaitant adopter des technologies open‑source de pointe

Services de bases de données gérés par le cloud (charge opérationnelle réduite et évolutif)

Si vous souhaitez réduire la charge opérationnelle sur site, envisagez d’utiliser un service RDB géré par le cloud. Les services typiques incluent :

• Amazon RDS for MySQL
• Un service géré par AWS
• Sauvegarde automatique et redondance intégrées
• Mises à jour automatiques possibles — nécessite prudence
• Google Cloud SQL for MySQL
• Un service géré par GCP
• Hautement évolutif et s’intègre aux autres services GCP
• Interface utilisateur conviviale facilite la gestion pour les débutants
• Avantages :
• Pas de maintenance du système d’exploitation ou du matériel requise
• Pas besoin de connaissances approfondies en infrastructure
• Inconvénients :
• Coût continu du service cloud s’accumule
• Le réglage fin peut être plus difficile
• Le mieux adapté à :
• Les opérations d’applications web de petite à moyenne taille
• Les startups ou entreprises web cherchant une efficacité opérationnelle

[Comparison Table] Résumé des principales options et fonctionnalités

La prochaine section organisera les étapes et les points clés lorsque vous effectuerez réellement la migration. Passons en revue les procédures pratiques pour éviter les échecs.

5. Étapes de migration MySQL et liste de contrôle (pour éviter les échecs)

La migration est « 80 % préparation »

Avec la migration vers la fin de vie de MySQL, il ne s’agit pas seulement d’une mise à niveau de version mais des procédures minutieuses et d’une préparation ample sont essentielles. Surtout dans les systèmes de production, garantir l’intégrité des données et la continuité du service est la priorité absolue.

Nous décomposons les étapes requises en cinq phases et les expliquons en détail.

ÉTAPE 1 : Enquête et inventaire de l’environnement actuel

Tout d’abord, vous devez rassembler la version MySQL, la configuration et les dépendances de votre système actuel.
Vérifiez les éléments suivants :

• Version et numéro de build de MySQL
• Jeu de caractères utilisé (tel que utf8mb4)
• Moteur de stockage (InnoDB, MyISAM)
• Syntaxe SQL ou fonctions utilisées (qui peuvent dépendre de la version)
• Applications connectées ou services externes

✅ Objectif : Identifier toutes les dépendances afin d’éviter les dysfonctionnements post‑migration

ÉTAPE 2 : Vérification de compatibilité

Vérifiez si la version cible est compatible avec votre environnement actuel. Pour les mises à niveau majeures de MySQL, les points suivants provoquent souvent des incompatibilités.

• Utilisation de syntaxes supprimées ou de mots réservés
• Variables ou paramètres système différents

🔎 La commande mysql_upgrade ou l’outil MySQL Shell Upgrade Checker Utility peut effectuer des diagnostics de compatibilité.

ÉTAPE 3 : Sauvegarde et création d’un environnement de test

Mettre à niveau directement en production est trop risqué.
Tout d’abord, obtenez une sauvegarde complète, puis utilisez‑la pour créer un environnement de mise en scène / test.

• Dump avec mysqldump ou mysqlpump
• Sauvegarde basée sur fichiers (telle que XtraBackup)
• Restauration dans l’environnement de test et réalisation de tests d’application

Dans cette phase, vous pouvez détecter les défauts ou erreurs SQL après migration à l’avance, ce qui minimise les problèmes lors de la migration en production.

ÉTAPE 4 : Migration des données vers l’environnement de production

Après vérification, vous passez à la migration vers l’environnement de production. Il est recommandé de la réaliser pendant la nuit ou les périodes de faible trafic si possible.

• Sauvegarde finale avant le passage en production
• Pause du service (installer une page de maintenance si possible)
• Importation des données dans la nouvelle base de données
• Ajustement des fichiers de configuration et des variables d’environnement

Notez également que le côté application peut nécessiter des changements d’endpoint de connexion pour MySQL, alors faites attention au timing du passage.

ÉTAPE 5 : Vérification opérationnelle et optimisation

Migration n’est pas terminée une fois le basculement effectué.
Vérifiez les éléments suivants pour confirmer le fonctionnement stable du nouvel environnement MySQL.

• Vérifier la connexion depuis les applications
• Vérifier les performances des requêtes SQL et l’absence d’erreurs
• Surveiller les fichiers journaux (journal d’erreurs, journal des requêtes lentes)
• Optimiser via les paramètres de cache ou la reconstruction d’index

Si nécessaire, exécuter ANALYZE TABLE ou OPTIMIZE TABLE pour récupérer les performances dégradées pendant la migration.

Checklist (Pour la revue finale)

✅ Confirmer la version actuelle et la configuration
✅ Pré-diagnostiquer la compatibilité
✅ Obtenir une sauvegarde complète
✅ Tester dans un environnement de pré-production
✅ Planifier et exécuter le basculement en production
✅ Surveiller les erreurs et les performances post‑migration

Le point clé pour une migration réussie est la « préparation organisationnelle ». En particulier pour la migration EOL, procédez à la préparation, à la vérification et au basculement de manière méthodique plutôt que précipitée.

6. Réponse EOL pour les services cloud (pour les utilisateurs AWS & GCP)

Même en utilisant MySQL dans le cloud, ne soyez pas complaisant

Même si vous utilisez MySQL dans des environnements cloud tels qu’Amazon RDS ou Google Cloud SQL, les problèmes liés à la fin de support (EOL) restent pertinents. Les services cloud mettent parfois en œuvre des « mises à niveau automatiques » ou des « retiraisons de service »** lorsqu’une version atteint l’EOL, il est donc important de planifier à l’avance.

Nous expliquons ici la gestion de l’EOL pour les principaux services cloud.

Amazon RDS pour MySQL : Attention aux mises à niveau automatiques

Avec le service géré Amazon RDS pour MySQL d’AWS, il y a eu plusieurs cas de retiraisons forcées de versions et de mises à niveau automatiques après la fin du support.

• MySQL 5.5 : Fin 2018 → Passé automatiquement à 5.6
• MySQL 5.6 : Fin 2021 → À partir de 2022, mise à niveau automatique vers 5.7

Cela peut entraîner un changement inattendu de la version MySQL pour les utilisateurs et provoquer des erreurs d’application ou une dégradation des performances.

✅ Contre‑mesure : Planifiez les mises à niveau à votre propre rythme

AWS envoie des notifications préalables par e‑mail ou via la console, mais si elles sont négligées, une mise à niveau automatique peut se produire.

Google Cloud SQL pour MySQL : Fin de vie de la première génération et poussée de migration

Avec le service géré Cloud SQL pour MySQL de Google Cloud, la retraite des anciennes versions et architectures a progressé.

• Les instances de première génération ne peuvent plus être créées
• Les versions ciblées pour l’EOL bénéficient d’une politique d’encouragement à la mise à niveau

Bien que Google tende à respecter la liberté des utilisateurs, il existe toujours une limite à la durée pendant laquelle le support peut être prolongé, il est donc nécessaire de procéder à une mise à niveau ou reconstruction précoce.

Notez également que dans Cloud SQL, des fonctionnalités étendues telles que les sauvegardes automatiques et la bascule existent, mais les paramètres par défaut du mode SQL ou les différences de fuseau horaire peuvent passer inaperçus et entraîner des problèmes.

✅ Important : Testez les paramètres spécifiques au cloud et la compatibilité à l’avance

Avantages du cloud et pièges de la réponse EOL

L’utilisation de services cloud apporte des avantages, mais si la réponse EOL est faible, elle peut devenir une source de problèmes.

Même dans le cloud, la responsabilité de la réponse EOL reste à l’utilisateur.

Checklist de réponse EOL cloud

✅ Confirmer la version MySQL que vous utilisez et son calendrier EOL
✅ Activer les paramètres de notification du fournisseur cloud (e‑mail, SNS)
✅ Vérifier si vous êtes soumis à une mise à niveau automatique
✅ Tester la nouvelle version dans un environnement de pré‑production
✅ Planifier les tâches ou ajustements côté application si nécessaire

Pour tirer pleinement parti de la commodité du cloud, vous ne devez pas simplement « le confier ». Au lieu de cela, vous avez besoin d’une supervision et d’une surveillance internes. En particulier pour l’EOL de MySQL, une préparation et une planification robustes sont nécessaires même dans les environnements cloud.

7. Questions fréquemment posées (FAQ)

Q1 : Puis-je continuer à utiliser une version MySQL après la fin du support ?

R : C’est techniquement possible, mais pas recommandé.
Une version EOL de MySQL ne reçoit aucun correctif de sécurité ou de bug. Par conséquent, le risque d’attaques exploitant des vulnérabilités augmente considérablement et vous pourriez violer les réglementations ou les politiques de sécurité.

Même si le système semble fonctionner correctement, vous êtes dans un état de risque élevé caché. Envisagez une mise à niveau ou une migration précoce.

Q2 : Quelle est la différence entre MySQL 8.0 et MySQL 8.4 LTS ?

R : MySQL 8.4 LTS est une édition stable soutenue sur le long terme.
MySQL 8.0 suit un cycle de versions régulier et est prévu pour perdre son support premier en avril 2025. En revanche, MySQL 8.4 LTS (Long Term Support) offre environ cinq ans de support prolongé en tant que version stable.

Si vous accordez de l’importance à la fiabilité à long terme et à l’utilisation en entreprise, la migration vers MySQL 8.4 LTS est recommandée.

Q3 : Combien coûte la migration ?

R : Le coût varie considérablement en fonction de l’ampleur et du choix de la migration.
Par exemple, si vous effectuez une mise à niveau sur le même serveur d’une version MySQL à une autre, le coût peut être nul. Cependant, migrer vers un service cloud ou passer à un autre produit (MariaDB ou TiDB) peut entraîner des coûts de conception, de construction, de test et de support technique.

La sauvegarde de la mitigation des temps d’arrêt et la préparation de l’environnement de test doivent également être incluses dans la planification des coûts.

Q4 : À quoi faut-il faire attention lors de la migration d’un système de production ?

R : Les tests préalables et la migration par phases sont essentielles.
En production, vous devez effectuer des vérifications de compatibilité, des sauvegardes, des tests en environnement de mise en scène. L’utilisation de réplicas en lecture ou d’un déploiement blue/green (exécution des environnements anciens et nouveaux côte à côte pendant la transition) aide à minimiser les temps d’arrêt.

Effectuez le travail pendant la nuit ou en dehors des heures de pointe pour plus de sécurité.

Q5 : Puis-je arrêter les mises à niveau automatiques dans le cloud ?

R : Vous pouvez contrôler certains paramètres, mais vous devez finalement suivre la politique du fournisseur.
Avec Amazon RDS ou Cloud SQL, vous pouvez reporter ou éviter les plannings de mise à niveau automatiques, mais une fois que la version atteint la fin de vie, des mises à niveau forcées peuvent survenir.

Éviter à long terme est difficile ; par conséquent, la mise à niveau planifiée par l’utilisateur est la méthode la plus fiable.

Q6 : Existe-t-il des critères pour choisir une base de données alternative ?

R : Oui : basez votre décision sur ces trois axes.

1. Compatibilité : Dans quelle mesure vos applications ou votre SQL actuel fonctionneront tel quel
2. Scalabilité & Préparation à l’avenir : Peut-il gérer une augmentation du volume de données et du trafic
3. Capacité opérationnelle : Pouvez-vous le maintenir en interne ou avez-vous besoin du support du fournisseur

En particulier dans les systèmes d’entreprise, il est plus important de s’aligner sur votre capacité opérationnelle réaliste plutôt que sur les tendances.

8. Résumé | La meilleure décision que vous pouvez prendre avant la fin du support

La fin de vie n’est pas « encore loin » mais déjà « à portée de main »

La fin de vie de MySQL n’est pas seulement un sujet pour quelques techniciens informatiques. C’est un problème qui affecte la sécurité, les performances, la disponibilité et la gestion des coûts à travers votre organisation.

En particulier, le support de MySQL 5.7 a déjà pris fin en octobre 2023 et 8.0 est prévu pour perdre son support premier en avril 2025. En d’autres termes, si vous pensez « il fonctionne encore donc c’est bon », vous pourriez déjà être dans un état de risque critique.

Une migration planifiée est la mesure d’évitement de risque la plus efficace

Comme décrit dans cet article, la migration n’est pas difficile si elle est effectuée par étapes.

• Inventorier la version actuelle
• Vérifier la compatibilité et sélectionner la destination de migration
• Tester dans un environnement de mise en scène
• Effectuer une migration par phases et basculer

Si vous suivez ces étapes, vous pouvez réaliser la migration en toute sécurité, évitant des problèmes tels que l’arrêt du service ou la perte de données.

Même si vous utilisez des services cloud, vous ne devez pas laisser cela uniquement au fournisseur. Au lieu de cela, vous devez comprendre votre propre situation et planifier activement votre stratégie de mise à niveau.

« Il n’est plus suffisant de dire que vous ne saviez pas »

Dans les opérations informatiques modernes, la prise de conscience continue de la maintenance est plus importante que la simple connaissance technique. Connaître les informations de fin de vie, évaluer les risques et choisir la meilleure destination de migration sont des compétences essentielles pour tous les ingénieurs d’exploitation et développeurs.

Final : Trois actions immédiates que vous devez entreprendre

1. Vérifiez la version de MySQL que votre système utilise
2. Identifiez la date de fin de vie (EOL) pour cette version et notez‑la
3. Discutez avec votre équipe de la possibilité de mettre à niveau ou de migrer vers une autre base de données

Traiter la fin de vie (EOL) de MySQL est comme une assurance qui prévient les incidents futurs.
Utilisez cet article comme catalyseur pour revoir votre cadre d’opérations sûres et durables.