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.

Neue Funktionen sind vor allem dann nützlich, wenn sie ein konkretes Betriebsproblem adressieren. Conseils pour l'optimiseur können etwa einen unerwünschten Ausführungsplan für eine einzelne komplexe Abfrage begrenzen. Sie ersetzen weder passende Indizes noch korrekte Join-Bedingungen oder aktuelle Statistiken und sollten nicht als globale Vorgabe für Kundenanwendungen eingesetzt werden.

Die zusätzlichen Auditfelder können Host, Port und verwendete TLS-Version einer eingehenden Verbindung erfassen. Die Schlüsseloption ssl_passphrase und die erweiterten GIS- oder Cursor-Funktionen rechtfertigen dagegen keinen pauschalen Versionswechsel. Ihr Nutzen entsteht nur bei Anwendungen, deren Architektur, Datenmodell und Sicherheitsvorgaben diese Fähigkeiten tatsächlich benötigen.

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

Ein MariaDB-Update im Managed oder Shared Hosting beginnt mit einer Inventur: Instanzen, Datenbanken, Connectoren, Plugins, Konfigurationsdateien, Replikationswege und betroffene Anwendungen müssen bekannt sein. Danach folgt eine Staging-Umgebung, die Produktionsdaten und Konfiguration nur unter den zulässigen Schutzvorgaben abbildet. So lassen sich Startprobleme und SQL-Abweichungen erkennen, bevor mehrere Mandanten betroffen sind.

Vor jedem begrenzten Rollout braucht es ein vollständiges Backup und einen dokumentierten Wiederherstellungsablauf. Entscheidend ist nicht allein, dass Sicherungsdateien vorhanden sind: Verantwortliche müssen prüfen, ob sich daraus ein konsistenter, für Anwendungen nutzbarer Datenstand wiederherstellen lässt. Anschließend kontrollieren sie Anmeldungen, Schreibvorgänge, Hintergrundjobs und typische Kundenpfade als Anwendungs-Regression. Die konkrete Vorgehensweise hängt vom eingesetzten Sicherungsverfahren und der Plattformarchitektur ab.

Ein Rückfallplan legt fest, wer entscheidet, welche Datenstände maßgeblich sind und wie Anwendungen bei einem Abbruch wieder auf den vorherigen konsistenten Stand wechseln. Das ist redaktionelle Betriebspraxis, keine Eigenschaft einer bestimmten MariaDB-Version. Replikation, Monitoring und Failover müssen deshalb in der jeweiligen Staging-Topologie geprüft werden, statt ihre Funktion aus einem erfolgreichen Update einer Einzelinstanz abzuleiten.

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

Nach einem MariaDB-Update beginnt eine Beobachtungsphase, keine automatische Optimierung. Zuerst ist zu unterscheiden, ob der Serverstart fehlschlägt, eine Anwendung keine Verbindung mehr aufbauen kann oder ein Replikationspfad abweicht. Diese Fehlerbilder haben unterschiedliche Ursachen und benötigen getrennte Artefakte, statt mit pauschalen Konfigurationsänderungen beantwortet zu werden.

Startfehler werden anhand des Server-Error-Logs und einer versionierten Inventur der tatsächlich geladenen Konfigurationsdateien eingegrenzt. In MariaDB 12.0 wurden beispielsweise big_tables et storage_engine entfernt. Solche Einträge dürfen nicht unverändert in my.cnf oder eingebundenen Konfigurationsfragmenten stehen; die dokumentierte Variablenreferenz und die Startmeldung zeigen, welche Einstellung konkret betroffen ist.

Bei Connectoren und Plugins sind installierte Pakete, geladene Modulversionen und die Fehlermeldung der Anwendung gemeinsam zu erfassen. Eine Repository-Auswahl allein garantiert keine zusammenpassende Installation: Bei einer gezielten Serverversion müssen Server-, Client-, Shared- und Common-Pakete versionsgleich geplant werden. Welche Namen und Stände verfügbar sind, hängt vom verwendeten Repository und Betriebssystem ab.

Anwendungsfehler lassen sich am besten mit einem reproduzierbaren, möglichst kleinen SQL-Fall und den zugehörigen Client- beziehungsweise Connector-Logs untersuchen. Eine lesende Bestandsaufnahme kann mit SELECT VERSION(); beginnen. Das Ergebnis identifiziert den antwortenden Datenbankserver, beweist aber weder die Kompatibilität eines ORM noch die korrekte Wirkung einer Anwendungskonfiguration.

Für Replikation gehören der dokumentierte Replikationsstatus, Binlog-Format, Server-IDs sowie Ereignisse rund um Failover und Rejoin in die Diagnoseakte. Temporäre Tabellen, die Topologie und Änderungen an Replikationsoptionen sind separat zu prüfen. Eine erfolgreiche lokale Schreibprobe genügt nicht, um Konsistenz und erwartetes Verhalten auf allen beteiligten Instanzen zu belegen.

Server- und Audit-Logs, Konfigurationsinventar, Versionsabfragen und reproduzierbare Abfragetests ergeben zusammen eine nachvollziehbare Fehlerkette. Sie erleichtert auch die Entscheidung, ob ein Rückfallplan ausgelöst werden muss. Aus einer höheren Versionsnummer folgt weder eine bestimmte Leistungswirkung noch ein universelles Tuning; Änderungen an Speicher-, Optimizer- oder Replikationsparametern benötigen eine konkrete Hypothese und eine prüfbare Wirkung.

Décider stratégiquement du score final

Der passende Zielstand richtet sich nach Plattformaufgabe und Betriebsmodell, nicht nach der Sammelbezeichnung MariaDB 12. Für klassische CMS-, Shop- und Webanwendungsdatenbanken haben Upgrade-Sicherheit, saubere Mandantentrennung und ein belastbarer Wiederherstellungsweg meist Vorrang vor einzelnen neuen SQL-Funktionen. Neue GIS-Funktionen oder Routinen sind kein eigenständiger Migrationsgrund, wenn die Anwendungen sie nicht verwenden.

Komplexe Reporting-Anwendungen können von Optimizer-Hints profitieren, wenn eine Analyse einen unerwünschten Ausführungsplan klar eingrenzt. Zuvor sind Indizes, Join-Bedingungen, Datenverteilung und Statistiken zu prüfen. Ein Hint ist eine gezielte Bindung an eine Planentscheidung und kann nach Datenwachstum oder geänderten Statistiken unpassend werden; er gehört daher mit Abfrage, Begründung und Rücknahmekriterium in die Anwendungsdokumentation.

Proxy- und Clusterumgebungen benötigen einen eigenen Testpfad. Für einen Proxy betrifft er insbesondere das Berechtigungsmodell des Servicekontos, die Sitzungswechsel und die Auditierbarkeit. Für Replikation oder Galera gehören Failover, Rejoin, Restore und das Verhalten temporärer Tabellen dazu. Ein erfolgreiches Upgrade einer einzelnen Instanz belegt nicht, dass diese Abläufe in der gesamten Topologie korrekt funktionieren.

Le Release-Strategie muss Innovation Releases und LTS getrennt bewerten. MariaDB beschreibt Innovation Releases als Rolling-Releases, die nach GA im Regelfall nicht fortlaufend mit Patch-Versionen gepflegt werden; der vorgesehene Weg führt zur nächsten Rolling-Serie. LTS-Releases werden dagegen drei Jahre ab GA gepflegt. Daraus folgt keine pauschale Zusage für Paket- oder Vertragssupport einer konkreten Hosting-Umgebung.

Vor der Entscheidung sind deshalb Paket- und Supportlage der Distribution, getestete Anwendungskompatibilität, ein nachgewiesenes Restore, das Sicherheitsmodell und der laufende Betriebsaufwand zusammen zu bewerten. MariaDB und MySQL sind trotz vieler gemeinsamer SQL-Muster nicht austauschbar: MariaDB verwendet ein eigenes GTID-Modell und unterstützt beispielsweise nicht MySQLs SET PERSIST. Migrationsannahmen aus einer MySQL-Umgebung müssen daher überprüft werden.

Für die Serie 12.0 ist 12.0.2 als stabiler GA-Stand dokumentiert, während 12.0.0 Preview und 12.0.1 Release Candidate waren. Diese Einordnung beschreibt den damaligen Reifestatus, ersetzt aber keine aktuelle Freigabeentscheidung. Unmittelbar vor Rollout oder Veröffentlichung müssen Betreiber angebotenen Paketstand, Betriebssystemunterstützung und aktuelle Release-Einstufung erneut gegen die Herstellerinformationen prüfen.

Entscheidend ist somit der konkret geprüfte Plattformstand mit seinen Abhängigkeiten und Betriebsregeln. Ein kontrollierter Rollout ist gerechtfertigt, wenn Kompatibilität, Rückfall und Verantwortlichkeiten nachweisbar vorbereitet sind. Fehlen diese Voraussetzungen, ist der Name MariaDB 12 kein Argument, Risiken im Shared Hosting oder in einer geschäftskritischen Datenbanklandschaft zu übernehmen.