MariaDB 12.0 : fonctionnalités, risques liés à la mise à jour et stratégie d'hébergement

Claser correctement MariaDB 12.0

Le nom „ MariaDB 12 “ ne désigne pas une version de produit uniforme et maintenue de manière permanente. Pour obtenir des informations techniques concrètes, il convient de se référer à la série « rolling » MariaDB 12.0 c'est ce qu'on entend par là. Au sein de cette série, les versions marquent différents degrés de maturité : la version 12.0.0 est sortie le 26 mars 2025 en avant-première, la version 12.0.1 le 5 juin 2025 en tant que version candidate, et la version 12.0.2 le 7 août 2025 en tant que version GA stable.

Les versions « Preview » et « Release Candidate » sont destinées à des fins de test et ne doivent pas être assimilées à une version stable de la plateforme. Le fait que la version 12.0.2 soit documentée comme « Stable » ou « GA » décrit en revanche le niveau de maturité de cette version précise. Il n'en découle ni que chaque installation doive être mise à jour immédiatement, ni que les versions ultérieures possèdent automatiquement les mêmes caractéristiques, paquets ou limites de fonctionnement.

Les branches ultérieures, telles que 12.1, 12.2 ou 12.3, doivent également être considérées séparément. Les fonctionnalités, corrections de bogues ou modifications des valeurs par défaut issues de ces séries ne constituent pas une preuve de MariaDB 12.0. Cela vaut également pour les branches de développement : une annonce ou une documentation y figurant ne remplace en aucun cas une information concernant la version publiée du serveur communautaire.

Avant tout déploiement, la plateforme doit donc procéder à une nouvelle vérification de la version du package effectivement prévue. Il convient notamment de vérifier la gamme de serveurs disponible, la compatibilité entre les paquets clients et les paquets complémentaires, la prise en charge par la version du système d’exploitation utilisée, ainsi que la classification actuelle de la version. Le contenu du référentiel et les paquets de distribution peuvent différer de la désignation générale du produit.

Distinguer le « rolling release » et la version LTS

Pour les plateformes d'hébergement, ce n'est pas seulement le numéro de version qui importe, mais aussi le Modèle de publication. MariaDB fait la distinction entre les versions « Innovation » et les versions LTS. Les versions « Innovation » apportent de nouvelles fonctionnalités à intervalles réguliers et, une fois leur version GA atteinte, elles intègrent généralement la série « Rolling » suivante. Les versions LTS, en revanche, sont prises en charge pendant trois ans à compter de leur date de sortie GA, selon le fabricant.

Une version GA stable ne répond donc qu'à la question de savoir si cette version spécifique a été publiée en tant que version stable. Elle ne fournit pas de réponse générale quant à la durée pendant laquelle les correctifs de sécurité seront disponibles, à la poursuite de la fourniture de paquets par un distributeur ou à la possibilité pour une base de clients existante de rester sur cette série sans migration. Ces points dépendent du contrat, de la distribution et de la liste actuelle des versions.

Une série d'innovations peut s'avérer appropriée lorsqu'une plateforme souhaite déployer rapidement une fonctionnalité clairement nécessaire et qu'elle est en mesure de tester de manière isolée les applications, les connecteurs et les processus opérationnels concernés. Pour cela, les équipes doivent prévoir de poursuivre sans délai le parcours de mise à niveau prévu. Dans le cas des offres multi-clients notamment, cela augmente la charge de travail liée aux validations, à la communication et aux procédures de repli.

A Cible LTS convient davantage aux plateformes standardisées comportant de nombreuses applications classiques, lorsque des fenêtres de maintenance planifiables et une version logicielle stable sur le long terme priment sur l'ajout de nouvelles fonctionnalités ponctuelles. Cela ne constitue pas une règle s'opposant aux versions innovantes : ce qui est déterminant, c'est de savoir si l'utilité d'une fonctionnalité justifie les tests supplémentaires et le passage prévisible à la série suivante.

Le choix doit donc tenir compte au minimum des besoins fonctionnels, de l’état actuel des paquets et du support, de la compatibilité testée des applications, de la capacité de restauration et de la charge de travail liée à l’exploitation. Pour une nouvelle installation, il ne suffit pas de considérer „ MariaDB 12 “ comme la version la plus récente. La plateforme opte délibérément pour un état de la base de données standardisé à long terme plutôt que pour l'utilisation de fonctionnalités à court terme.

Évaluer les nouvelles fonctionnalités en tenant compte de leurs limites

MariaDB 12.0 ajoute Conseils pour l'optimiseur afin d'influencer de manière plus ciblée les plans d'exécution, par exemple pour l'ordre des jointures, l'optimisation des plages ou certains algorithmes de jointure. Les extensions concernent également les composants d'index triés par ordre décroissant dans le cadre du « Loose Index Scan » et de l'« Index Condition Pushdown ». En matière d’hébergement, il s’agit avant tout d’un outil de diagnostic pour des requêtes problématiques isolées, et non d’un substitut à des index adaptés, à des conditions de jointure correctes et à des statistiques de tables à jour.

Une recommandation peut limiter un scénario indésirable, mais peut elle-même s'avérer préjudiciable en cas d'augmentation du volume de données ou de modification des statistiques. Elle doit donc s'inscrire dans le cadre d'une analyse reproductible de l'application concernée et ne pas être appliquée comme une règle globale dans les serveur de base de données. Pour les bases de données typiques des CMS et des boutiques en ligne, la simple existence de ces conseils ne constitue pas une raison suffisante pour passer à MariaDB.

Lors de l'audit, le plugin d'audit de la version 12.0 enregistre également l'hôte et le port des connexions entrantes, ainsi que la version TLS utilisée. Pour les accès passant par des proxys, des NAT ou des équilibreurs de charge, cela peut améliorer l'identification forensic. Cet avantage ne se concrétise toutefois que grâce à une collecte centralisée et sécurisée des journaux, ainsi qu’à des règles de conservation définies ; les données de journaux supplémentaires doivent s’inscrire dans le cadre de la planification des capacités et de la protection des données.

En matière de chiffrement, la prise en charge de SHA-2 est disponible dans file_key_management.so et ssl_passphrase Modules prêts. Les environnements de réplication disposent désormais d'options pour les tables temporaires ainsi que d'une variable permettant de gérer les événements liés à leur propre ID de serveur. De plus, la version 12.0 apporte notamment SYS_REFCURSOR, une limite de curseurs par session et des fonctions SIG telles que la validation, la simplification et la conversion en géohash. Ces outils ne sont utiles que pour certaines applications et topologies spécifiques.

MariaDB Server, MaxScale et Galera restent des composants distincts : MaxScale dispose de ses propres versions et configurations, et les modifications liées à Galera concernent exclusivement les clusters. De même, la compatibilité avec MySQL ne signifie pas une interchangeabilité sans vérification préalable. MariaDB utilise son propre modèle GTID et ne prend pas en charge, par exemple, la fonctionnalité de MySQL SET PERSIST. Les nouvelles fonctionnalités SIG peuvent être utiles aux applications de géodonnées basées sur MySQL 8, mais ne justifient généralement pas une mise à niveau pour les bases de données Web classiques.

Comparer les versions et les fonctionnalités

Pour l'exploitation de la plateforme, c'est la version spécifique au sein de la série qui est déterminante. MariaDB 12.0.0 était une préversion, 12.0.1 une version candidate et ce n'est qu'à partir de la version 12.0.2 qu'elle est documentée comme stable ou GA. Ces statuts indiquent différents niveaux de maturité ; ils ne permettent pas de déterminer si la version est adaptée à un déploiement d'hébergement spécifique, à un système d'exploitation ou à un contrat de support.

Les nouvelles fonctionnalités sont particulièrement utiles lorsqu'elles permettent de résoudre un problème opérationnel concret. Conseils pour l'optimiseur peuvent, par exemple, limiter un plan d'exécution indésirable pour une requête complexe isolée. Elles ne remplacent ni les index adaptés, ni les conditions de jointure correctes, ni les statistiques à jour, et ne doivent pas être utilisées comme règle générale pour les applications des clients.

Les champs d'audit supplémentaires peuvent enregistrer l'hôte, le port et la version TLS utilisée pour une connexion entrante. L'option de clé ssl_passphrase En revanche, les fonctionnalités avancées du SIG ou du curseur ne justifient pas un changement de version généralisé. Leur utilité ne se concrétise que dans le cadre d'applications dont l'architecture, le modèle de données et les exigences de sécurité nécessitent réellement ces capacités.

Préparer la mise à jour de MariaDB de manière contrôlée

Une mise à jour de MariaDB dans le cadre d'un hébergement géré ou partagé commence par un inventaire : il faut recenser les instances, les bases de données, les connecteurs, les plugins, les fichiers de configuration, les chemins de réplication et les applications concernées. Vient ensuite un environnement de test qui reproduit les données de production et la configuration uniquement dans le respect des exigences de sécurité autorisées. Cela permet de détecter les problèmes de démarrage et les anomalies SQL avant que plusieurs clients ne soient affectés.

Avant tout déploiement limité, il est nécessaire de procéder à une sauvegarde complète et de disposer d'une procédure de restauration documentée. Le simple fait que des fichiers de sauvegarde soient disponibles n’est pas suffisant : les responsables doivent vérifier s’il est possible de restaurer à partir de ceux-ci un état des données cohérent et exploitable par les applications. Ils contrôlent ensuite les connexions, les opérations d’écriture, les tâches en arrière-plan et les parcours types des clients en tant que Régression des applications. La procédure concrète dépend de la méthode de sécurisation utilisée et de l'architecture de la plateforme.

Un plan de reprise après incident définit qui décide quels états des données font autorité et comment les applications reviennent à l'état cohérent précédent en cas d'interruption. Il s’agit là d’une pratique opérationnelle éditoriale, et non d’une caractéristique propre à une version spécifique de MariaDB. La réplication, la surveillance et le basculement doivent donc être testés dans la topologie de staging concernée, plutôt que de déduire leur fonctionnement à partir d’une mise à jour réussie d’une instance unique.

MariaDB 12.0 supprime les variables système big_tables, large_page_size et storage_engine. Les entrées existantes doivent donc être converties en my.cnf et dans tous les fragments de configuration associés, puis évalués pour l'état cible. Le nettoyage doit être effectué avant la mise à jour du paquet ; dans le cas de large_page_size Il convient en outre de faire la distinction entre la variable MariaDB supprimée et une configuration HugePages du système d'exploitation qui lui est indépendante.

La planification des paquets mérite également une étape à part entière : un référentiel peut contenir plusieurs versions de MariaDB, et les paquets « serveur », « client », « partagés » et « communs » associés doivent être choisis avec des versions identiques. La version du système d'exploitation et les sources des paquets font partie intégrante de la mise en production. Pour les dépendances au niveau de l'hôte, l'article consacré à Nouveautés importantes concernant les serveurs d'hébergement sous Linux avec le noyau 6.x un contexte supplémentaire ; il ne remplace toutefois pas le contrôle de préparation spécifique à la base de données.

Configurer correctement les cas particuliers

En cas de requêtes de reporting instables, le diagnostic doit commencer par l'analyse des plans d'exécution, des index, des conditions de jointure et des statistiques des tables. Ce n'est que lorsqu'un plan indésirable a été identifié de manière reproductible qu'une indication à l'optimiseur peut constituer une limitation ciblée. Cette indication fait partie intégrante de la requête concernée et doit être incluse dans un audit documenté, car la croissance des données ou la modification des statistiques peuvent altérer son effet par la suite.

Les requêtes en lecture sont idéales pour effectuer un état des lieux sans risque. Exécutez-les à partir d'un compte disposant uniquement des droits d'accès nécessaires à cette fin ; elles ne modifient ni les données, ni les droits, ni la configuration du serveur. Les résultats indiquent le serveur de base de données réellement connecté et permettent de vérifier les hypothèses formulées dans la documentation de déploiement.

SELECT VERSION();
SHOW VARIABLES LIKE 'max_open_cursors';
SHOW VARIABLES LIKE 'create_tmp_table_binlog_formats';

Dans une architecture proxy, SET SESSION AUTHORIZATION Ce n'est pas une fonctionnalité de confort, mais une modification du modèle de sécurité. Le changement de session nécessite le privilège SET USER et n'est pas disponible dans les transactions, les instructions préparées ou les procédures stockées.

Les versions compatibles de MaxScale peuvent utiliser les identifiants de service pour la connexion au serveur backend, puis basculer vers l'identité du client. Pour cela, il faut disposer d'un serveur backend MariaDB 12 ou plus récent et du privilège SET USER nécessaire pour le compte de service. Cette fonctionnalité ne découle toutefois pas automatiquement d'un backend MariaDB 12.0 seul : avant le déploiement, il convient de vérifier la combinaison spécifique entre le serveur MariaDB, la version de MaxScale et la configuration.

Le paramètre MaxScale use_service_credentials Détermine, dans les versions compatibles, si MaxScale doit d'abord se connecter au backend à l'aide des identifiants enregistrés dans le service, puis basculer vers l'identité du client. Le compte de service ne doit pas disposer de droits d’administration supplémentaires au-delà des droits techniquement nécessaires. L’audit et une procédure de coupure d’urgence documentée doivent être adaptés au modèle de connexion et de mise en pool.

Les topologies de réplication et Galera nécessitent un parcours de test dédié pour le basculement, la réintégration et la restauration. Les options relatives aux tables temporaires ou au traitement des ID de serveur identiques ne doivent pas être modifiées sans une bonne compréhension du format du journal binaire, de l'ID de serveur et du chemin de retour. De plus, une optimisation Galera ne constitue pas une garantie générale de performances pour les clusters, car le profil de charge et la latence du réseau restent des facteurs déterminants.

Quiconque évalue des tables internes, des structures temporaires ou des moteurs de stockage dans son environnement devrait considérer le rôle de chaque moteur indépendamment de la migration de version. L'article consacré à la Moteur de stockage MariaDB Aria en hébergement classe ces questions d'exploitation. Toutefois, pour la décision de mise à niveau, le facteur déterminant reste de savoir si l'application concrète et ses processus opérationnels fonctionnent de manière reproductible sur la version cible.

Sécuriser les changements de session et les audits

SET SESSION AUTHORIZATION est un élément constitutif d'architectures de connexion conçues de manière réfléchie, et non pas simplement un moyen de faciliter l'administration. Cette commande permet à un compte autorisé d'agir sous l'identité d'un autre utilisateur au cours de la session en cours. La condition préalable est le privilège SET USER. La responsabilité de la connexion et de la vérification d'identité est ainsi partiellement transférée des connexions individuelles des clients vers un composant contrôlé de la plateforme.

Ce modèle peut s'avérer utile pour un proxy, mais le serveur MariaDB et MaxScale restent des produits distincts, chacun disposant de son propre système de gestion des versions. Seules les versions de MaxScale prenant en charge l'utilisation d'identifiants de service suivie d'un changement d'identité peuvent mettre en œuvre ce processus. Un backend MariaDB 12.0 n’étend pas automatiquement cette fonctionnalité à une branche MaxScale plus ancienne ou configurée différemment.

Dans une combinaison prise en charge, le proxy se connecte au serveur MariaDB à l'aide du compte de service, puis bascule vers l'identité utilisateur demandée. Le paramètre use_service_credentials nécessite pour cela un serveur backend MariaDB 12 ou plus récent, ainsi que SET USER pour le compte de service. Avant la mise en place, il convient donc de vérifier conjointement les versions de MariaDB et MaxScale concrètement utilisées, la configuration et le mode d'authentification prévu.

Le compte de service est utilisé en raison de la possibilité de Le changement d'identité : un enjeu crucial pour la sécurité. Le privilège SET USER ne lui confère pas automatiquement tous les droits d'administration globaux ; de plus, il ne doit disposer que des autorisations techniquement nécessaires. Lors d'un changement de session, il est notamment possible de contourner le verrouillage du compte, l'expiration du mot de passe, l'authentification et la vérification REQUIRE-SSL du compte cible. De plus, ce changement n’est pas disponible au sein des transactions, des instructions préparées ou des procédures stockées.

Pour un hébergement multi-clients, cela signifie que les comptes clients restent logiquement séparés, et que le cycle d'interconnexion autorisé est documenté et limité. De plus, la plateforme doit disposer d’un mécanisme d’arrêt d’urgence, par exemple via le blocage du compte de service ou la suppression de la voie de connexion concernée, conformément à une procédure d’incident définie. Le choix de la mesure appropriée doit être coordonné en tenant compte du regroupement des connexions, des sessions en cours et des répercussions sur les autres clients.

Dans MariaDB 12.0, le plugin d'audit ajoute, pour les connexions entrantes, l'hôte, le port et la version TLS utilisée. Ces informations permettent de mieux identifier les accès provenant de derrière un NAT, un équilibreur de charge ou un proxy. Elles ne remplacent toutefois pas une identification fiable lorsqu'un système en amont modifie les informations de source ou ne transmet que sa propre adresse au serveur de base de données.

Entrera en vigueur Audit en commençant par un processus opérationnel : les journaux doivent être collectés de manière centralisée, protégés contre toute modification non autorisée et gérés selon une durée de conservation définie. Les droits d’accès pour la consultation et l’exportation doivent être dissociés, tout comme les responsabilités en matière d’alerte et d’analyse. Sans mesure, il est impossible de déterminer, à partir de la version, si des données de journal supplémentaires ont une incidence notable sur la capacité ou les performances d’une plateforme donnée.

En cas d'incident de sécurité, les opérateurs doivent pouvoir déterminer quelle identité a été définie par le proxy, par quel accès la session a été établie et quelles données d'audit sont disponibles à ce sujet. Des contrôles réguliers et documentés de la mise hors service et de la disponibilité des journaux sont plus importants qu’une journalisation aussi exhaustive que possible. En particulier, un journal d’audit ne doit en aucun cas se substituer à une politique d’accès, au chiffrement du transport ou à une gestion sécurisée des secrets.

Surveiller le fonctionnement après la mise à niveau

Après une mise à jour de MariaDB, une phase d'observation commence ; aucune optimisation automatique n'est effectuée. Il convient tout d'abord de déterminer si le Démarrage du serveur en cas d'échec, lorsqu'une application ne parvient plus à établir une connexion ou lorsqu'un chemin de réplication présente un écart. Ces scénarios d'erreur ont des causes différentes et nécessitent des solutions spécifiques, plutôt que d'être traités par des modifications de configuration génériques.

Les erreurs de démarrage sont identifiées à l'aide du journal d'erreurs du serveur et d'un inventaire versionné des fichiers de configuration effectivement chargés. Dans MariaDB 12.0, par exemple, big_tables et storage_engine supprimées. Ces entrées ne doivent pas être conservées telles quelles dans my.cnf ou dans des fragments de configuration intégrés ; la référence de variable documentée et le message d'initialisation indiquent quel paramètre est concrètement concerné.

Pour les connecteurs et les plugins, il convient de répertorier les paquets installés, les versions des modules chargés et le message d'erreur de l'application. Le choix d'un référentiel ne garantit pas à lui seul une installation compatible : pour une version de serveur spécifique, les paquets serveur, client, partagés et communs doivent être planifiés avec des versions identiques. Les noms et versions disponibles dépendent du référentiel et du système d'exploitation utilisés.

Le meilleur moyen d'analyser les erreurs d'application consiste à utiliser un cas SQL reproductible et aussi simple que possible, ainsi que les journaux correspondants du client ou du connecteur. Un état des lieux en lecture seule peut être réalisé à l'aide de SELECT VERSION(); Commencer. Le résultat identifie le serveur de base de données qui répond, mais ne prouve ni la compatibilité d'un ORM ni le bon fonctionnement d'une configuration d'application.

En ce qui concerne la réplication, le dossier de diagnostic doit inclure l'état de réplication documenté, le format du journal binaire, les identifiants des serveurs ainsi que les événements liés au basculement et à la réintégration. Les tables temporaires, la topologie et les modifications apportées aux options de réplication doivent faire l'objet d'une vérification séparée. Un test d’écriture local réussi ne suffit pas à prouver la cohérence et le comportement attendu sur toutes les instances concernées.

Les journaux de serveur et d'audit, l'inventaire des configurations, les requêtes de version et les tests de requêtes reproductibles constituent ensemble une chaîne d'erreurs traçable. Elle facilite également la décision quant à la nécessité de déclencher un plan de reprise après incident. Un numéro de version plus élevé n'implique ni une amélioration spécifique des performances, ni un réglage universel ; toute modification des paramètres de mémoire, d'optimisation ou de réplication nécessite une hypothèse concrète et un effet vérifiable.

Décider stratégiquement du score final

La version cible appropriée dépend de la mission de la plateforme et du modèle d'exploitation, et non de l'appellation générique « MariaDB 12 ». Pour les bases de données classiques de CMS, de boutiques en ligne et d'applications web, la sécurité des mises à niveau, une séparation claire des locataires et un processus de restauration fiable priment généralement sur les nouvelles fonctionnalités SQL individuelles. Les nouvelles fonctionnalités ou routines SIG ne constituent pas en soi un motif de migration si les applications ne les utilisent pas.

Les applications de reporting complexes peuvent tirer parti des conseils d'optimisation lorsqu'une analyse permet d'identifier clairement un plan d'exécution indésirable. Il convient au préalable de vérifier les index, les conditions de jointure, la répartition des données et les statistiques. Une indication est un lien ciblé avec une décision de plan d'exécution et peut devenir inadaptée suite à une augmentation du volume de données ou à une modification des statistiques ; elle doit donc figurer dans la documentation de l'application, accompagnée de la requête, de la justification et des critères de retrait.

Les environnements proxy et en cluster nécessitent un parcours de test spécifique. Pour un proxy, cela concerne notamment le modèle d'autorisation du compte de service, les changements de session et l'auditabilité. Pour la réplication ou Galera, cela inclut le basculement, la réintégration, la restauration et le comportement des tables temporaires. Une mise à niveau réussie d'une instance isolée ne prouve pas que ces processus fonctionnent correctement dans l'ensemble de la topologie.

Le Stratégie de lancement doit distinguer les versions « Innovation » des versions LTS. MariaDB décrit les versions « Innovation » comme des versions « rolling release » qui, en règle générale, ne font pas l'objet d'un maintenance continue par le biais de versions de correctifs après la disponibilité générale (GA) ; le processus prévu mène à la série « rolling » suivante. Les versions LTS, en revanche, sont maintenues pendant trois ans à compter de la disponibilité générale (GA). Il n'en découle toutefois aucun engagement général concernant la prise en charge sous forme de paquets ou de contrat pour un environnement d'hébergement spécifique.

Avant de prendre une décision, il convient donc d’évaluer globalement la gamme de packages et le niveau d’assistance de la distribution, la compatibilité testée des applications, une restauration éprouvée, le modèle de sécurité et les coûts d’exploitation courants. MariaDB et MySQL ne sont pas interchangeables malgré de nombreux modèles SQL communs : MariaDB utilise son propre modèle GTID et ne prend pas en charge, par exemple, les SET PERSIST. Les hypothèses de migration provenant d'un environnement MySQL doivent donc être vérifiées.

Pour la série 12.0, la version 12.0.2 est documentée comme version GA stable, tandis que les versions 12.0.0 étaient des préversions et la version 12.0.1 une version candidate. Cette classification décrit l'état de maturité à l'époque, mais ne remplace en aucun cas une décision de mise en production actuelle. Juste avant le déploiement ou la publication, les opérateurs doivent vérifier à nouveau la version du progiciel proposée, la prise en charge du système d'exploitation et la classification actuelle de la version par rapport aux informations fournies par le fabricant.

Ce qui est donc déterminant, c'est la version de la plateforme ayant fait l'objet de tests concrets, avec ses dépendances et ses règles de fonctionnement. Un déploiement contrôlé se justifie lorsque la compatibilité, les procédures de repli et les responsabilités ont été préparées de manière vérifiable. En l’absence de ces conditions préalables, le nom « MariaDB 12 » ne saurait constituer un argument pour assumer des risques dans le cadre d’un hébergement mutualisé ou d’un environnement de bases de données critiques pour l’activité.