MariaDB 12.0: functies, risico’s bij updates en hostingstrategie

MariaDB 12.0 correct indelen

De benaming „MariaDB 12“ verwijst niet naar een uniforme, permanent onderhouden productversie. Voor concrete technische informatie geldt hier de rolling-serie MariaDB 12.0 bedoeld. Binnen deze serie geven de releases verschillende rijpheidsniveaus aan: 12.0.0 verscheen op 26 maart 2025 als preview, 12.0.1 op 5 juni 2025 als release candidate en 12.0.2 op 7 augustus 2025 als stabiele GA-release.

Preview- en Release Candidate-versies zijn bedoeld om te testen en kunnen niet worden gelijkgesteld aan een stabiel platformdoel. Dat 12.0.2 als Stable of GA wordt aangeduid, geeft daarentegen de volwassenheidsstatus van juist deze release weer. Hieruit volgt noch dat elke installatie onmiddellijk moet worden omgezet, noch dat latere versies automatisch dezelfde eigenschappen, pakketten of bedrijfslimieten hebben.

Ook latere versies, zoals 12.1, 12.2 of 12.3, moeten afzonderlijk worden bekeken. Functies, foutcorrecties of gewijzigde standaardwaarden uit dergelijke series vormen geen bewijs voor MariaDB 12.0. Dit geldt ook voor ontwikkelingsvertakkingen: een aankondiging of documentatie daar is geen vervanging voor een mededeling over de status van een gepubliceerde communityserver.

Vóór een uitrol moet het platform daarom opnieuw worden afgestemd op de daadwerkelijk geplande pakketstatus. Er moet met name worden gecontroleerd of de beschikbare serverserie, de bij elkaar passende client- en aanvullende pakketten, de ondersteuning door de gebruikte versie van het besturingssysteem en de huidige releaseclassificatie in orde zijn. De inhoud van de repository en de distributiepakketten kunnen afwijken van de algemene productnaam.

Het verschil tussen Rolling Release en LTS

Voor hostingplatforms is niet alleen het versienummer van belang, maar ook het onderliggende Release-model. MariaDB maakt onderscheid tussen innovatieversies en LTS-versies. Innovatieversies brengen om de korte tijd nieuwe functies en gaan na hun GA-status doorgaans over naar de volgende rolling-serie. LTS-versies worden daarentegen volgens de fabrikant drie jaar na de GA ondersteund.

Een stabiele GA-release geeft dus alleen antwoord op de vraag of deze specifieke versie als stabiel is uitgebracht. Het geeft geen algemeen antwoord op vragen als hoe lang beveiligingsupdates beschikbaar blijven, of een distributeur pakketten blijft leveren, of dat een bestaand klantenbestand zonder migratie op de serie kan blijven. Deze punten zijn afhankelijk van het contract, de distributie en het actuele release-overzicht.

Een innovatieserie kan aangewezen zijn wanneer een platform een duidelijk benodigde functie in een vroeg stadium wil implementeren en de betrokken applicaties, connectoren en bedrijfsprocessen afzonderlijk kan testen. Hiervoor moeten teams rekening houden met het tijdig voortzetten van het geplande upgradepad. Vooral bij multi-tenant-oplossingen verhoogt dit de inspanningen op het gebied van goedkeuringen, communicatie en noodprocedures.

A LTS-doelstand past beter bij gestandaardiseerde platforms met veel klassieke toepassingen, wanneer planbare onderhoudsvensters en een langdurig stabiele softwareversie belangrijker zijn dan afzonderlijke nieuwe functies. Dit is geen regel die innovatieve releases in de weg staat: het is doorslaggevend of het nut van een functie de extra tests en de te verwachten overstap naar de volgende serie rechtvaardigt.

Bij de keuze moet daarom op zijn minst rekening worden gehouden met de functionele behoeften, de huidige pakket- en ondersteuningssituatie, de geteste compatibiliteit met applicaties, de herstelbaarheid en de personeelskosten voor het beheer. Voor een nieuwe installatie volstaat het niet om „MariaDB 12“ als de modernste naam te beschouwen. Het platform maakt bewust een afweging tussen het gebruik van functies op korte termijn en een op lange termijn gestandaardiseerde databasestatus.

Nieuwe functies met beperkingen beoordelen

MariaDB 12.0 aangevuld Optimalisatietips om uitvoeringsplannen gerichter te beïnvloeden, bijvoorbeeld voor de volgorde van joins, bereikoptimalisatie of bepaalde join-algoritmen. Uitbreidingen hebben bovendien betrekking op in aflopende volgorde gesorteerde indexonderdelen bij Loose Index Scan en Index Condition Pushdown. Voor hosting is dit vooral een diagnose-instrument voor afzonderlijke problematische query's, geen vervanging voor geschikte indexen, correcte join-voorwaarden en actuele tabelstatistieken.

Een richtlijn kan een ongewenst scenario beperken, maar kan na een toename van de gegevenshoeveelheid of gewijzigde statistieken zelf nadelig uitpakken. Daarom hoort deze thuis in een reproduceerbare analyse van de betreffende toepassing en niet als algemene richtlijn in de databaseserver. Voor typische CMS- en webshopdatabases is de beschikbaarheid van dergelijke tips op zich geen overtuigende reden om MariaDB bij te werken.

Tijdens de audit registreert de audit-plugin in versie 12.0 bovendien de host en poort van inkomende verbindingen, evenals de gebruikte TLS-versie. Voor toegang via proxyservers, NAT of load balancers kan dit de forensische toewijzing verbeteren. Het voordeel ontstaat echter pas door een centrale, beveiligde logboekverzameling en vastgelegde bewaarregels; extra logboekgegevens moeten passen binnen de capaciteits- en gegevensbeschermingsplanning.

Voor versleuteling is er ondersteuning voor SHA-2 in file_key_management.so en ssl_passphrase Bouwstenen klaar. Replicatieomgevingen krijgen opties voor tijdelijke tabellen en een variabele voor het afhandelen van gebeurtenissen met de eigen server-ID. Daarnaast biedt versie 12.0 onder andere SYS_REFCURSOR, een cursorlimiet per sessie en GIS-functies zoals validatie, vereenvoudiging en geohash-conversie. Deze tools zijn alleen geschikt voor bepaalde toepassingen en topologieën.

MariaDB Server, MaxScale en Galera blijven afzonderlijke componenten: MaxScale heeft eigen versies en configuraties, en wijzigingen die betrekking hebben op Galera hebben uitsluitend betrekking op clusters. Ook betekent MySQL-compatibiliteit niet dat de componenten zonder controle onderling uitwisselbaar zijn. MariaDB maakt gebruik van een eigen GTID-model en ondersteunt bijvoorbeeld niet MySQL’s SET PERSIST. Nieuwe GIS-functies kunnen nuttig zijn voor geodatatoepassingen die op MySQL 8 zijn gebaseerd, maar vormen voor gewone webdatabases meestal geen reden om te upgraden.

Releasestatus en functies vergelijken

Voor het gebruik op het platform is de specifieke status binnen de serie doorslaggevend. MariaDB 12.0.0 was een preview, 12.0.1 een release candidate en pas 12.0.2 wordt aangemerkt als stabiel of GA. Deze statussen duiden op verschillende mate van volwassenheid; ze zeggen niets over de vraag of de serie geschikt is voor een bepaalde hostingimplementatie, een besturingssysteem of een ondersteuningscontract.

Nieuwe functies zijn vooral nuttig als ze een concreet bedrijfsprobleem aanpakken. Optimalisatietips kunnen bijvoorbeeld een ongewenst uitvoeringsplan voor een enkele complexe query beperken. Ze zijn geen vervanging voor geschikte indexen, correcte join-voorwaarden of actuele statistieken en mogen niet worden gebruikt als algemene richtlijn voor klanttoepassingen.

De extra auditvelden kunnen de host, de poort en de gebruikte TLS-versie van een inkomende verbinding vastleggen. De sleuteloptie ssl_passphrase De uitgebreide GIS- of cursorfuncties vormen daarentegen geen reden voor een algemene versie-upgrade. Het nut ervan komt pas tot uiting bij toepassingen waarvan de architectuur, het gegevensmodel en de beveiligingsvoorschriften deze mogelijkheden daadwerkelijk vereisen.

MariaDB-update zorgvuldig voorbereiden

Een MariaDB-update bij managed of shared hosting begint met een inventarisatie: instanties, databases, connectoren, plug-ins, configuratiebestanden, replicatiepaden en betrokken applicaties moeten bekend zijn. Daarna volgt een staging-omgeving, waarin productiedata en configuratie uitsluitend volgens de toegestane beveiligingsvoorschriften worden gerepliceerd. Zo kunnen opstartproblemen en SQL-afwijkingen worden opgespoord voordat meerdere klanten hierdoor worden getroffen.

Voorafgaand aan elke beperkte uitrol zijn een volledige back-up en een gedocumenteerde herstelprocedure vereist. Het is niet alleen van cruciaal belang dat er back-upbestanden aanwezig zijn: de verantwoordelijken moeten controleren of hieruit een consistente, voor applicaties bruikbare gegevensset kan worden hersteld. Vervolgens controleren ze aanmeldingen, schrijfbewerkingen, achtergrondtaken en typische klanttrajecten als Regressietesten van applicaties. De concrete werkwijze hangt af van de gebruikte beveiligingsmethode en de platformarchitectuur.

Een noodplan bepaalt wie beslist welke gegevensstanden doorslaggevend zijn en hoe applicaties bij een afbreking terugkeren naar de vorige consistente stand. Dit is gangbare praktijk bij het beheer, geen kenmerk van een bepaalde MariaDB-versie. Replicatie, monitoring en failover moeten daarom worden getest in de betreffende staging-topologie, in plaats van hun werking af te leiden uit een succesvolle update van een enkele instantie.

In MariaDB 12.0 zijn de systeemvariabelen verwijderd big_tables, large_page_size en storage_engine. Bestaande vermeldingen moeten daarom in my.cnf en in alle betrokken configuratiefragmenten worden gevonden en beoordeeld voor de doelstatus. De opschoning moet plaatsvinden vóór de pakketupdate; bij large_page_size Daarnaast moet er onderscheid worden gemaakt tussen de verwijderde MariaDB-variabele en een daarvan onafhankelijke HugePages-configuratie van het besturingssysteem.

Ook de pakketplanning verdient een aparte stap: een repository kan meerdere MariaDB-versies bevatten, en bijbehorende server-, client-, shared- en common-pakketten moeten dezelfde versie hebben. De versie van het besturingssysteem en de pakketbronnen maken daarbij deel uit van de goedkeuring. Voor afhankelijkheden op hostniveau biedt het artikel over relevante wijzigingen voor hostingservers met Linux-kernel 6.x extra context; het vervangt echter niet de databasespecifieke staging-controle.

Speciale gevallen veilig configureren

Bij onstabiele rapportagequery’s moet de diagnose beginnen met uitvoeringsplannen, indexen, join-voorwaarden en tabelstatistieken. Pas wanneer een ongewenst plan op reproduceerbare wijze is geïdentificeerd, kan een optimizer-hint een gerichte oplossing bieden. De hint hoort bij de betreffende query en moet worden opgenomen in een gedocumenteerde evaluatie, omdat gegevensgroei of gewijzigde statistieken het effect ervan later kunnen beïnvloeden.

Leesopdrachten zijn geschikt voor een risicovrije inventarisatie. Voer ze uit met een account dat alleen over de daarvoor benodigde inzagerechten beschikt; ze wijzigen noch gegevens, noch rechten, noch de serverconfiguratie. De resultaten geven de daadwerkelijk verbonden databaseserver weer en helpen bij het controleren van aannames uit de implementatiedocumentatie.

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

In een proxy-architectuur is SET SESSION AUTHORIZATION geen comfortfunctie, maar een ingreep in het beveiligingsmodel. Voor het wisselen van sessie is het privilege vereist SET USER en is niet beschikbaar binnen transacties, prepared statements of opgeslagen procedures.

Ondersteunde versies van MaxScale kunnen inloggegevens voor de backend-verbinding gebruiken en vervolgens overschakelen naar de identiteit van de client. Hiervoor zijn een MariaDB 12- of nieuwere backend-server en het recht SET USER vereist voor het serviceaccount. Deze mogelijkheid vloeit echter niet automatisch voort uit een MariaDB 12.0-backend alleen: vóór de uitrol moet de specifieke combinatie van MariaDB Server, MaxScale-versie en configuratie worden gecontroleerd.

De MaxScale-instelling use_service_credentials bepaalt in de daarvoor geschikte versies of MaxScale zich eerst met de in de service opgeslagen inloggegevens bij de backend aanmeldt en vervolgens overschakelt naar de client-identiteit. Het serviceaccount mag geen extra beheerdersrechten krijgen die verder gaan dan de technisch noodzakelijke rechten. Auditering en een gedocumenteerde nooduitschakeling moeten aansluiten bij het verbindings- en poolingmodel.

Replicatie- en Galera-topologieën vereisen een eigen testtraject voor failover, rejoin en herstel. Opties voor tijdelijke tabellen of de omgang met identieke server-ID's mogen niet worden gewijzigd zonder kennis van het binlog-formaat, de server-ID en het terugkeerpad. Een Galera-optimalisatie is bovendien geen algemene prestatiegarantie voor clusters, omdat het belastingsprofiel en de netwerklatentie doorslaggevend blijven.

Wie interne tabellen, tijdelijke structuren of opslagengines in de omgeving evalueert, moet de rol van de betreffende engine los van de versiemigratie bekijken. Het artikel over de MariaDB Aria-opslagengine bij hosting beoordeelt dergelijke gebruiksvraagstukken. Voor de beslissing over een upgrade blijft het echter doorslaggevend of de concrete toepassing en de bijbehorende bedrijfsprocessen op het doelplatform op dezelfde manier kunnen functioneren.

Zorg voor een veilige wisseling van sessie en audit

SET SESSION AUTHORIZATION is een bouwsteen voor bewust ontworpen verbindingsarchitecturen, en niet louter een vergemakkelijking voor de administratie. Met dit commando kan een bevoegde gebruiker binnen de huidige sessie handelen onder de identiteit van een andere gebruiker. Voorwaarde hiervoor is het privilege SET USER. Hierdoor verschuift de verantwoordelijkheid voor de aanmelding en identiteitscontrole gedeeltelijk van individuele klantaccounts naar een gecontroleerd platformonderdeel.

Voor een proxy kan dit patroon zinvol zijn, maar MariaDB Server en MaxScale blijven afzonderlijke producten met hun eigen versiebeheer. Alleen MaxScale-versies die het gebruik van inloggegevens voor services met daaropvolgende identiteitswisseling ondersteunen, kunnen dit proces mogelijk maken. Een MariaDB 12.0-backend breidt een oudere of anders geconfigureerde MaxScale-branch niet automatisch uit met deze mogelijkheid.

In een ondersteunde combinatie meldt de proxy zich met het serviceaccount aan bij de MariaDB-server en schakelt vervolgens over naar de gevraagde gebruikersidentiteit. De instelling use_service_credentials vereist hiervoor een MariaDB 12 of nieuwere backend-server, evenals SET USER voor het serviceaccount. Vóór de implementatie moeten daarom de daadwerkelijk gebruikte versies van MariaDB en MaxScale, de configuratie en de beoogde authenticatiemethode gezamenlijk worden gecontroleerd.

De serviceaccount is vanwege de mogelijkheid om Identiteitswijziging is van cruciaal belang voor de veiligheid. Het voorrecht SET USER verleent hem niet automatisch willekeurige globale beheersrechten; bovendien mag hij alleen de technisch noodzakelijke machtigingen krijgen. Bij het wisselen van sessie kunnen onder andere accountblokkering, het verlopen van het wachtwoord, authenticatie en de REQUIRE-SSL-controle van het doelaccount worden omzeild. De omschakeling is bovendien niet beschikbaar binnen transacties, prepared statements of opgeslagen procedures.

Voor hosting met meerdere klanten betekent dit: klantenaccounts blijven logisch gescheiden en de toegestane uitwisselingscyclus wordt gedocumenteerd en beperkt. Daarnaast moet het platform beschikken over een nooduitschakeling, bijvoorbeeld door het serviceaccount te blokkeren of de betreffende verbindingsroute te verwijderen volgens een vastgestelde incidentprocedure. Welke maatregel geschikt is, moet worden afgestemd op verbindingspooling, bestaande sessies en de gevolgen voor andere klanten.

De Audit-plugin voegt in MariaDB 12.0 bij inkomende verbindingen de host, de poort en de gebruikte TLS-versie toe. Deze gegevens helpen om toegang achter NAT, load balancers of proxyservers beter te classificeren. Ze vormen echter geen vervanging voor een betrouwbare toewijzing wanneer een voorgeschakeld systeem de broninformatie wijzigt of alleen zijn eigen adres doorgeeft aan de databaseserver.

Treedt in werking Audit Allereerst via een bedrijfsproces: logbestanden moeten centraal worden verzameld, worden beschermd tegen ongeoorloofde wijzigingen en worden beheerd op basis van een vastgestelde bewaartermijn. Toegangsrechten voor inzage en export moeten net zo goed worden gescheiden als de verantwoordelijkheid voor alarmering en onderzoek. Of aanvullende loggegevens de capaciteit of prestaties van een specifiek platform merkbaar beïnvloeden, kan zonder meting niet uit de versie worden afgeleid.

Bij een beveiligingsincident moeten beheerders kunnen achterhalen welke identiteit de proxy heeft ingesteld, via welke toegang de sessie tot stand is gekomen en welke auditgegevens hierover beschikbaar zijn. Regelmatige, gedocumenteerde controles van de uitschakeling en de beschikbaarheid van de logbestanden zijn belangrijker dan een zo uitgebreid mogelijke logboekregistratie. Een auditlog mag met name geen vervanging worden voor een rechtenconcept, transportversleuteling of veilig geheimbeheer.

De werking na de upgrade controleren

Na een MariaDB-update begint een observatiefase; er vindt geen automatische optimalisatie plaats. Eerst moet worden nagegaan of de Server opstarten mislukt, een toepassing geen verbinding meer kan maken of een replicatiepad afwijkt. Deze foutscenario’s hebben verschillende oorzaken en vereisen afzonderlijke oplossingen, in plaats van dat ze met algemene configuratiewijzigingen worden aangepakt.

Startfouten worden opgespoord aan de hand van het serverfoutenlogboek en een inventaris met versienummers van de daadwerkelijk geladen configuratiebestanden. In MariaDB 12.0 werden bijvoorbeeld big_tables en storage_engine verwijderd. Dergelijke vermeldingen mogen niet ongewijzigd in my.cnf of in de configuratiefragmenten zijn opgenomen; uit de gedocumenteerde variabelereferentie en het startbericht blijkt welke instelling concreet wordt beïnvloed.

Bij connectoren en plug-ins moeten geïnstalleerde pakketten, geladen moduleversies en de foutmelding van de toepassing gezamenlijk worden vastgelegd. De keuze van een repository alleen is geen garantie voor een compatibele installatie: bij een specifieke serverversie moeten server-, client-, shared- en common-pakketten met dezelfde versie worden gepland. Welke namen en versies beschikbaar zijn, hangt af van de gebruikte repository en het besturingssysteem.

Fouten in de applicatie kunnen het beste worden onderzocht aan de hand van een reproduceerbaar, zo klein mogelijk SQL-voorbeeld en de bijbehorende client- of connectorlogs. Een inventarisatie van de huidige situatie kan worden gemaakt met SELECT VERSION(); beginnen. Het resultaat identificeert de database-server die reageert, maar bewijst noch de compatibiliteit van een ORM, noch de correcte werking van een applicatieconfiguratie.

Wat replicatie betreft, moeten de gedocumenteerde replicatiestatus, het binlog-formaat, de server-ID’s en gebeurtenissen rondom failover en rejoin in het diagnoserapport worden opgenomen. Tijdelijke tabellen, de topologie en wijzigingen in de replicatie-instellingen moeten afzonderlijk worden gecontroleerd. Een geslaagde lokale schrijftest is niet voldoende om de consistentie en het verwachte gedrag op alle betrokken instanties aan te tonen.

Server- en auditlogs, configuratie-inventaris, versieopvragingen en reproduceerbare opvragingstests vormen samen een een begrijpelijke reeks fouten. Het maakt het ook gemakkelijker om te beslissen of een noodplan moet worden geactiveerd. Een hoger versienummer leidt noch tot een specifiek prestatie-effect, noch tot een universele afstemming; wijzigingen aan parameters voor opslag, de optimizer of replicatie vereisen een concrete hypothese en een controleerbaar effect.

De eindstand strategisch bepalen

De juiste einddoelstelling hangt af van de taak van het platform en het bedrijfsmodel, niet van de verzamelnaam MariaDB 12. Voor klassieke CMS-, webshop- en webapplicatiedatabases hebben upgrade-veiligheid, een duidelijke scheiding tussen clients en een robuust herstelproces meestal voorrang boven afzonderlijke nieuwe SQL-functies. Nieuwe GIS-functies of -routines vormen geen op zichzelf staande reden voor migratie als de applicaties er geen gebruik van maken.

Complexe rapportagetoepassingen kunnen baat hebben bij Optimizer-hints wanneer een analyse een ongewenst uitvoeringsplan duidelijk afbakent. Vooraf moeten indexen, join-voorwaarden, gegevensverdeling en statistieken worden gecontroleerd. Een hint is een gerichte koppeling aan een planbeslissing en kan na gegevensgroei of gewijzigde statistieken ongeschikt worden; daarom hoort deze, samen met de query, de motivering en het intrekingscriterium, thuis in de applicatiedocumentatie.

Proxy- en clusteromgevingen vereisen een apart testtraject. Voor een proxy heeft dit met name betrekking op het autorisatiemodel van het serviceaccount, de sessiewisselingen en de controleerbaarheid. Voor replicatie of Galera horen failover, rejoin, restore en het gedrag van tijdelijke tabellen hier bij. Een succesvolle upgrade van een enkele instantie bewijst niet dat deze processen in de gehele topologie correct functioneren.

De Releasestrategie moet innovatiereleases en LTS afzonderlijk beoordelen. MariaDB beschrijft innovatiereleases als rolling releases, die na GA in de regel niet continu met patchversies worden onderhouden; de beoogde route leidt naar de volgende rolling-serie. LTS-releases worden daarentegen drie jaar vanaf de GA onderhouden. Hieruit volgt geen algemene toezegging voor pakket- of contractondersteuning van een specifieke hostingomgeving.

Alvorens een beslissing te nemen, moeten daarom de pakket- en ondersteuningssituatie van de distributie, de geteste compatibiliteit van applicaties, een bewezen herstelprocedure, het beveiligingsmodel en de lopende exploitatiekosten gezamenlijk worden beoordeeld. MariaDB en MySQL zijn ondanks veel gemeenschappelijke SQL-patronen niet onderling uitwisselbaar: MariaDB maakt gebruik van een eigen GTID-model en ondersteunt bijvoorbeeld niet MySQL's SET PERSIST. Migratieaannames uit een MySQL-omgeving moeten daarom worden gecontroleerd.

Voor de 12.0-serie is 12.0.2 gedocumenteerd als stabiele GA-versie, terwijl 12.0.0 een preview en 12.0.1 een release candidate waren. Deze indeling geeft de toenmalige ontwikkelingsstatus weer, maar vervangt geen actuele beslissing over de vrijgave. Vlak voor de uitrol of publicatie moeten beheerders de aangeboden pakketversie, de ondersteuning voor het besturingssysteem en de huidige releaseclassificatie opnieuw toetsen aan de informatie van de fabrikant.

Bepalend is dus de concreet geteste stand van het platform, met zijn afhankelijkheden en bedrijfsregels. Een gecontroleerde uitrol is gerechtvaardigd als compatibiliteit, terugvalplannen en verantwoordelijkheden aantoonbaar zijn voorbereid. Als deze voorwaarden ontbreken, is de naam MariaDB 12 geen reden om risico's te nemen bij shared hosting of in een bedrijfskritische databaseomgeving.