Fin de vie MySQL

MySQL 8.0 en fin de vie : passer en 8.4 LTS ou migrer vers MariaDB ?

MySQL 8.0 n'est plus maintenu par Oracle depuis le 30 avril 2026. Il ne recevra plus de correctifs de sécurité communautaires. Voici les dates officielles, les options réalistes, les changements qui cassent en passant à 8.4 LTS, et les cas où MariaDB est un meilleur choix.

Auditer ma base avant migration Cadrer en 15 min

Les dates qui comptent

Sources : documentation MySQL, Amazon RDS et endoflife.date, vérifiées le 28 septembre 2026.

Version	Sortie	Fin de support	Statut
MySQL 8.0	Avril 2018	30 avril 2026 (dernière version : 8.0.46)	Fin de vie
MySQL 8.4 LTS	30 avril 2024	30 avril 2029 (Premier), puis Extended Support	Supportée
MySQL 9.7 LTS	21 avril 2026	5 ans Premier + 3 ans Extended	Supportée (LTS actuelle)
Innovation (26.x)	Trimestrielle, ex. 26.7 le 28 juillet 2026	Jusqu'à la version Innovation ou LTS suivante	Courte durée
Amazon RDS for MySQL 8.0	—	Support standard terminé le 31 juillet 2026 ; Extended Support payant jusqu'au 31 juillet 2029	Prolongation payante

endoflife.date/mysql · Amazon RDS for MySQL versions · MySQL Releases: Innovation and LTS

Ce que « fin de vie » change concrètement

Oracle ne publie plus de version 8.0 : la 8.0.46 (avril 2026) est la dernière. Les failles découvertes après cette date ne seront plus corrigées dans la version communautaire. Ce n'est pas théorique : la version 8.0 maintenue par Amazon RDS en Extended Support, publiée en septembre 2026, liste à elle seule plus de 30 CVE corrigées. Sur un serveur 8.0 auto-hébergé, ces correctifs n'arrivent pas, sauf à souscrire un support post-fin de vie auprès d'un tiers (Percona en propose un).

Votre base continue de tourner, rien ne s'arrête le jour J. Le risque est ailleurs : conformité (audits de sécurité, NIS2, exigences clients), paquets des distributions qui disparaissent, et une montée de version qui devient plus lourde à mesure que l'écart se creuse.

Sur Amazon RDS, le support standard de MySQL 8.0 s'est terminé le 31 juillet 2026 : les instances encore en 8.0 basculent en RDS Extended Support, facturé en plus, jusqu'au 31 juillet 2029 au plus tard. Le tarif augmente en troisième année (à partir du 1er août 2028). C'est une prolongation, pas une solution.

LTS, Innovation, et la nouvelle numérotation

Depuis 2023, MySQL suit deux voies. Les versions LTS (8.4, puis 9.7) ont 5 ans de support Premier et 3 ans d'Extended, et ne reçoivent que des correctifs : aucune fonctionnalité n'est retirée au sein d'une série. Les versions Innovation sortent chaque trimestre et ne sont supportées que jusqu'à la suivante.

Après la 9.7 LTS, MySQL est passé à une numérotation calendaire : la 26.7 (juillet 2026) est une version Innovation, pas une LTS. Pour la production, les deux cibles raisonnables sont donc 8.4 et 9.7.

Point important : on ne saute pas une série LTS. Depuis 8.0, le chemin supporté est 8.0 → 8.4, puis 8.4 → 9.7 si vous voulez aller plus loin. Pas de 8.0 → 9.7 direct.

Vos options, sans langue de bois

Aucune option n'est gratuite. La bonne dépend de votre application, pas d'une préférence de fournisseur.

Option	Pour	Contre	Pour qui
Rester en 8.0	Pas de projet, rien ne change	Plus de correctifs de sécurité communautaires d'Oracle ; chaque nouvelle CVE reste ouverte	Seulement en transition courte et documentée
Support étendu payant (RDS, ou tiers comme Percona en auto-hébergé)	Gagne du temps, les correctifs de sécurité continuent	Coût récurrent, la montée de version est seulement repoussée	Migration planifiée mais pas prête
MySQL 8.4 LTS	Chemin direct supporté depuis 8.0, support jusqu'en 2029, pas de suppression au sein de la série	Changements incompatibles à traiter (auth, syntaxe de réplication, valeurs par défaut)	La plupart des parcs MySQL 8.0 : le chemin le moins risqué
MySQL 9.7 LTS	Horizon de support le plus long	Passage obligatoire par 8.4 (on ne saute pas une série LTS)	Équipes prêtes à faire deux sauts, ou 8.4 puis 9.7
Versions Innovation (26.x)	Dernières fonctionnalités	Supportées seulement jusqu'à la version Innovation ou LTS suivante	Test et dev, rarement la production
Percona Server for MySQL 8.4	Compatible MySQL, compléments open source	Mêmes changements incompatibles 8.0 → 8.4	Équipes voulant rester compatibles MySQL avec un autre éditeur
MariaDB (LTS 11.8 / 12.3)	Open source, Galera intégré, pas de dépendance à Oracle	Pas un remplacement direct de MySQL 8 : migration logique, JSON, GTID, comptes	Quand sortir de la feuille de route d'Oracle est un objectif en soi

8.0 → 8.4 : ce qui casse vraiment

La 8.4 a été la première LTS, donc le moment où Oracle a fait le ménage. La liste officielle est longue ; voici les points à vérifier en priorité.

Authentification : mysql_native_password n'est plus activé par défaut en 8.4 (réactivable avec mysql_native_password=ON) et disparaît en 9.x. Les vieux connecteurs PHP, Java ou Python qui ne gèrent pas caching_sha2_password ne peuvent pas s'authentifier sur les comptes qui l'utilisent ; réactiver mysql_native_password ne sert que de transition.
Syntaxe de réplication : CHANGE MASTER TO, SHOW SLAVE STATUS, START SLAVE, RESET MASTER, SHOW MASTER STATUS et les mots-clés MASTER_* sont supprimés. Remplacez-les par CHANGE REPLICATION SOURCE TO, SHOW REPLICA STATUS, START REPLICA, RESET BINARY LOGS AND GTIDS, SHOW BINARY LOG STATUS. Scripts, supervision et outils de bascule sont concernés.
Variables supprimées : expire_logs_days (→ binlog_expire_logs_seconds), default_authentication_plugin (→ authentication_policy), binlog_transaction_dependency_tracking. Un my.cnf qui les contient empêche le serveur de démarrer.
Valeurs par défaut InnoDB modifiées : innodb_adaptive_hash_index passe à OFF, innodb_change_buffering à none, innodb_io_capacity de 200 à 10000, innodb_flush_method à O_DIRECT si le système le permet (sinon fsync) sous Linux. Les performances peuvent changer, dans un sens ou dans l'autre : mesurez.
Divers : FLUSH HOSTS supprimé, --skip-host-cache et --ssl retirés, plugins keyring_file, keyring_encrypted_file et keyring_oci remplacés par leurs composants.

Et MariaDB ?

MariaDB n'est plus un remplacement direct de MySQL 8. Les deux projets ont divergé, et la documentation MariaDB liste elle-même les points durs :

Pas de migration en place : MySQL 8 a remplacé les fichiers .frm par un dictionnaire de données que MariaDB ne lit pas. La migration passe par un dump logique (voir mariadb-dump vs mydumper) ou par réplication.
JSON : binaire côté MySQL, alias de LONGTEXT côté MariaDB. Les fonctions JSON sont proches, mais les opérateurs -> et ->>, très courants dans le code MySQL, n'existent pas dans les LTS actuelles de MariaDB (ils arrivent avec la 13.1) : à réécrire en JSON_EXTRACT() / JSON_UNQUOTE(). Les colonnes et index générés sur du JSON sont aussi à vérifier.
Réplication MySQL 8 → MariaDB : les GTID sont incompatibles, elle se fait par position de binlog, et seulement depuis MariaDB 10.6.21, 10.11.11 et 11.4.5, à trois conditions côté MySQL : colonnes JSON converties en TEXT, binlog_row_value_options='' et binlog_transaction_compression=0. Avec beaucoup de JSON, prévoyez plutôt une bascule par dump.
Mots de passe : depuis MariaDB 11.4.9 et 11.8.4, le plugin caching_sha2_password (bibliothèque auth_mysql_sha2, à charger : il n'est pas installé par défaut) permet de recréer les comptes avec leur empreinte MySQL existante, sans changer les mots de passe. MariaDB le présente comme un outil de migration et recommande de passer ensuite à PARSEC. Attention : l'empreinte contient des caractères non imprimables, elle ne se copie pas depuis un terminal.

MariaDB a du sens quand vous voulez sortir de la feuille de route d'Oracle, profiter de Galera Cluster intégré, ou consolider sur un moteur déjà présent dans votre parc. Les LTS recommandées pour un nouveau déploiement sont la 11.8 et la 12.3 (la 12.3 a trois ans de support communautaire, jusqu'en juin 2029) ; la 10.11 et la 11.4 restent maintenues. Si votre seul objectif est de retrouver du support, 8.4 LTS est plus simple : même moteur, même outillage.

Checklist de montée de version

1Inventorier versions, tailles, topologies de réplication, connecteurs et versions des bibliothèques clientes.
2Lancer l'Upgrade Checker de MySQL Shell (util.checkForServerUpgrade()) contre chaque serveur, avec targetVersion à 8.4 et configPath vers le my.cnf. Il ne voit pas tout : il ne remplace pas les tests applicatifs.
3Nettoyer le my.cnf des variables supprimées et décider explicitement des nouvelles valeurs par défaut InnoDB.
4Lister les comptes encore en mysql_native_password et tester les connecteurs applicatifs en caching_sha2_password.
5Réécrire scripts, supervision et outils de bascule utilisant la syntaxe MASTER / SLAVE.
6Monter un réplica 8.4 d'un primaire 8.0, le laisser tourner sous charge réelle, comparer les temps de requête.
7Sauvegarde complète testée en restauration juste avant la bascule, et plan de retour arrière écrit.
8Basculer par promotion du réplica 8.4 plutôt qu'en place, quand la topologie le permet : la fenêtre d'interruption est plus courte.

Ce que nous prenons en charge

Nous accompagnons les montées de version MySQL 5.7, 8.0 et 8.4 en standalone et en réplication classique, ainsi que les migrations MySQL vers MariaDB. MySQL InnoDB Cluster et Group Replication sont hors de notre périmètre.

Avant de trancher entre 8.4 et MariaDB, l'audit MySQL / MariaDB passe en revue le schéma, les connecteurs, la réplication et les requêtes, pour chiffrer les deux chemins sur votre base plutôt que sur une généralité. Une fois migré, l'infogérance prend le relais pour les mises à jour mineures.

Questions fréquentes

Quand MySQL 8.0 est-il arrivé en fin de vie ?

Le 30 avril 2026. La dernière version communautaire est la 8.0.46, publiée en avril 2026. Sur Amazon RDS, le support standard s'est terminé le 31 juillet 2026, avec un Extended Support payant jusqu'au 31 juillet 2029.

Peut-on passer directement de MySQL 8.0 à 9.7 ?

Non. On ne saute pas une série LTS : il faut passer de 8.0 à 8.4, puis de 8.4 à 9.7. La 26.7 est une version Innovation, supportée seulement jusqu'à la version Innovation ou LTS suivante.

Mon application va-t-elle casser en 8.4 ?

Les points à vérifier en premier sont l'authentification (mysql_native_password désactivé par défaut), la syntaxe de réplication MASTER/SLAVE supprimée et des variables retirées du my.cnf. L'Upgrade Checker de MySQL Shell et un réplica 8.4 sous charge réelle en révèlent l'essentiel avant la bascule, sans dispenser des tests applicatifs.

MariaDB est-il compatible avec MySQL 8 ?

Largement au niveau SQL, mais pas au niveau fichiers : pas de migration en place, JSON stocké différemment, GTID incompatibles, comptes à recréer (les mots de passe peuvent être conservés depuis MariaDB 11.4.9 / 11.8.4). Une migration vers MariaDB est un vrai projet, qui se justifie surtout si vous voulez sortir de l'écosystème Oracle.

Pages liées

Encore des serveurs MySQL 8.0 en production ?

On inventorie votre parc, on chiffre le passage en 8.4 et l'option MariaDB, et on prépare une bascule avec retour arrière.

Voir l'audit Cadrer en 15 min

Démarrez votre projet MariaDB infogéré

Discutons de vos besoins en bases de données. Notre équipe DBA vous conseille sur l'architecture optimale pour votre cas d'usage.

Appel découverte15 min avec un expert DBA 01 77 62 42 42Appelez-nous directement Emailcontact@rdem-systems.com

RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise