MariaDB 12.0: Funktioner, risici ved opdateringer og hostingstrategi

Korrekt klassificering af MariaDB 12.0

Betegnelsen „MariaDB 12“ beskriver ikke en ensartet produktversion, der vedligeholdes løbende. For konkrete tekniske oplysninger henvises her til den rullende serie MariaDB 12.0 menes. Inden for denne serie markerer udgivelserne forskellige modenhedsniveauer: 12.0.0 udkom den 26. marts 2025 som en preview, 12.0.1 udkom den 5. juni 2025 som release candidate, og 12.0.2 udkom den 7. august 2025 som en stabil GA-udgivelse.

Preview- og Release Candidate-versioner er beregnet til afprøvning og kan ikke sidestilles med en stabil platform. At 12.0.2 er dokumenteret som »Stable« eller »GA«, beskriver derimod netop denne udgivelses modenhedsstatus. Det betyder hverken, at alle installationer straks skal opgraderes, eller at senere versioner automatisk vil have de samme egenskaber, pakker eller driftsgrænser.

Også senere versioner som 12.1, 12.2 eller 12.3 skal betragtes separat. Funktioner, fejlrettelser eller ændrede standardværdier fra sådanne serier er ikke bevis for MariaDB 12.0. Det samme gælder for udviklingsgrene: En meddelelse eller dokumentation der er ikke en erstatning for en oplysning om den offentliggjorte status for community-serveren.

Inden en udrulning skal platformen derfor igen afstemmes med den faktisk planlagte pakkestatus. Der skal især kontrolleres den tilgængelige serverserie, at klient- og tillægspakkerne passer sammen, at den anvendte operativsystemversion understøtter dem samt den aktuelle release-klassificering. Indholdet i repositoryet og distributionspakkerne kan afvige fra den generelle produktbetegnelse.

Forskellen mellem Rolling Release og LTS

For hostingplatforme er det ikke kun versionsnummeret, der er relevant, men også det underliggende Udgivelsesmodel. MariaDB skelner mellem innovationsudgivelser og LTS-udgivelser. Innovationsudgivelser introducerer nye funktioner med korte mellemrum og følger som regel, efter deres GA-status, vejen til den næste rullende serie. LTS-udgivelser vedligeholdes derimod ifølge producenten i tre år fra GA.

En stabil GA-udgivelse besvarer således kun spørgsmålet om, hvorvidt netop denne version er blevet udgivet som stabil. Den giver ikke et generelt svar på, hvor længe der vil blive udgivet sikkerhedsrettelser, om en distributør fortsat leverer pakker, eller om en eksisterende kundebase kan forblive på serien uden at skulle migrere. Disse punkter afhænger af kontrakten, distributionen og den aktuelle oversigt over udgivelser.

En innovationsserie kan være hensigtsmæssig, hvis en platform ønsker at indføre en funktion, der er et klart behov for, på et tidligt tidspunkt, og kan teste de berørte applikationer, konnektorer og driftsprocesser isoleret. Til dette formål skal teams planlægge at fortsætte ad den fastlagte opgraderingsvej i god tid. Især i forbindelse med multiklientløsninger øger dette arbejdsbyrden i forbindelse med godkendelser, kommunikation og nødprocedurer.

En LTS-målstand passer bedre til standardiserede platforme med mange klassiske applikationer, når planlagte vedligeholdelsesvinduer og en længerevarende stabil softwareversion er vigtigere end enkelte nye funktioner. Dette er ikke en regel, der udelukker innovationsudgivelser: Det afgørende er, om fordelene ved en funktion retfærdiggør de ekstra test og den forventede overgang til den næste serie.

Valget bør derfor som minimum tage højde for funktionsbehov, den aktuelle status for pakker og support, testet applikationskompatibilitet, gendannelsesmuligheder og personaleomkostninger i forbindelse med driften. Ved en nyinstallation er det ikke tilstrækkeligt blot at betragte „MariaDB 12“ som det mest moderne navn. Platformen vælger bevidst mellem kortvarig udnyttelse af funktioner og en langsigtet standardiseret databasestatus.

Vurdering af nye funktioner med begrænsninger

MariaDB 12.0 supplerer Optimeringsforslag for at kunne påvirke eksekveringsplaner mere målrettet, f.eks. med hensyn til join-rækkefølger, rækkeviddeoptimering eller bestemte join-algoritmer. Udvidelserne omfatter desuden faldende sorterede indekselementer ved Loose Index Scan og Index Condition Pushdown. For hosting er dette først og fremmest et diagnoseværktøj til enkelte problematiske forespørgsler, ikke en erstatning for passende indekser, korrekte sammenkædningsbetingelser og opdaterede tabelstatistikker.

En retningslinje kan begrænse en uønsket plan, men kan selv have en negativ indvirkning efter stigende datamængder eller ændrede statistikker. Den hører derfor hjemme i en reproducerbar analyse af den pågældende applikation og ikke som en global retningslinje i databaseserver. For typiske CMS- og webshoppedatabaser er tilgængeligheden af sådanne tip i sig selv ikke en overbevisende grund til at opdatere til MariaDB.

Under en audit registrerer audit-pluginet i version 12.0 desuden værten og porten for indgående forbindelser samt den anvendte TLS-version. For adgang via proxyservere, NAT eller load balancere kan dette forbedre den forensiske tilknytning. Fordelen opnås dog først gennem en central, adgangsbeskyttet logindsamling og fastlagte opbevaringsregler; yderligere logdata skal passe ind i kapacitets- og databeskyttelsesplanlægningen.

Hvad angår kryptering, er der støtte for SHA-2 i file_key_management.so og ssl_passphrase Byggeblokke klar. Replikationsmiljøer får muligheder for midlertidige tabeller samt en variabel til håndtering af hændelser med eget server-ID. Derudover indeholder version 12.0 blandt andet SYS_REFCURSOR, en cursor-begrænsning pr. session samt GIS-funktioner som validering, forenkling og geohash-konvertering. Disse værktøjer er kun nyttige i de tilfælde, hvor de passer til de pågældende anvendelser og topologier.

MariaDB Server, MaxScale og Galera forbliver separate komponenter: MaxScale har sine egne versioner og konfigurationer, og ændringer, der vedrører Galera, gælder udelukkende klynger. Ligeledes betyder MySQL-kompatibilitet ikke, at komponenterne kan udskiftes uden nærmere undersøgelse. MariaDB anvender sin egen GTID-model og understøtter for eksempel ikke MySQLs SET PERSIST. Nye GIS-funktioner kan være en hjælp for geodata-applikationer, der er baseret på MySQL 8, men er som regel ikke en grund til at opgradere almindelige webdatabaser.

Sammenligning af udgivelsesstatus og funktioner

For driften af platformen er den konkrete status inden for serien afgørende. MariaDB 12.0.0 var en preview, 12.0.1 en release candidate, og først 12.0.2 er dokumenteret som stabil eller GA. Disse statusangivelser markerer forskellige modenhedsgrader; de siger ikke noget om, hvorvidt serien er egnet til en bestemt hosting-udrulning, et operativsystem eller en supportkontrakt.

Nye funktioner er især nyttige, når de løser et konkret driftsproblem. Optimeringsforslag kan f.eks. begrænse en uønsket eksekveringsplan for en enkelt kompleks forespørgsel. De erstatter hverken passende indekser, korrekte sammenkædningsbetingelser eller opdaterede statistikker og bør ikke anvendes som en generel standard for kundernes applikationer.

De ekstra auditfelter kan registrere vært, port og den anvendte TLS-version for en indgående forbindelse. Nøgleindstillingen ssl_passphrase og de udvidede GIS- eller markørfunktioner er derimod ikke grund nok til et generelt versionsskifte. Deres nytteværdi kommer kun til udtryk i applikationer, hvor arkitekturen, datamodellen og sikkerhedskravene rent faktisk kræver disse funktioner.

Kontrolleret forberedelse af MariaDB-opdatering

En MariaDB-opdatering i managed eller shared hosting begynder med en oversigt: Instanser, databaser, connectorer, plugins, konfigurationsfiler, replikeringsveje og berørte applikationer skal være kendt. Derefter følger et testmiljø, der kun afspejler produktionsdata og konfiguration i overensstemmelse med de tilladte sikkerhedskrav. På denne måde kan opstartsproblemer og SQL-afvigelser opdages, inden flere kunder bliver berørt.

Før enhver begrænset udrulning er det nødvendigt at foretage en fuldstændig sikkerhedskopiering og udarbejde en dokumenteret genoprettelsesprocedure. Det er ikke kun afgørende, at der findes sikkerhedskopier: De ansvarlige skal kontrollere, om det er muligt at gendanne en konsistent datatilstand, der kan bruges af applikationerne. Derefter kontrollerer de logins, skriveoperationer, baggrundsopgaver og typiske kunderejser som Regressionstest af applikationer. Den konkrete fremgangsmåde afhænger af den anvendte sikkerhedsprocedure og platformens arkitektur.

En genopretningsplan fastlægger, hvem der beslutter, hvilke datatilstande der er gældende, og hvordan applikationer i tilfælde af et afbræk vender tilbage til den forudgående konsistente tilstand. Dette er en redaktionel driftspraksis og ikke en egenskab ved en bestemt MariaDB-version. Replikering, overvågning og failover skal derfor testes i den pågældende staging-topologi i stedet for at antage, at de fungerer korrekt ud fra en vellykket opdatering af en enkelt instans.

MariaDB 12.0 fjerner systemvariablerne big_tables, large_page_size og storage_engine. Eksisterende poster skal derfor i my.cnf og alle involverede konfigurationsfragmenter skal findes og vurderes i forhold til måltilstanden. Oprydningen skal foregå før pakkeopdateringen; ved large_page_size Der skal desuden skelnes mellem den fjernede MariaDB-variabel og en HugePages-konfiguration i operativsystemet, der er uafhængig af denne.

Også pakkeplanlægningen fortjener et særskilt trin: Et repository kan indeholde flere MariaDB-versioner, og tilhørende server-, klient-, delte og fælles-pakker bør have samme version. Operativsystemversionen og pakkekilderne er en del af godkendelsen. For afhængigheder på værtsniveau findes der en artikel om Relevante ændringer for hosting-servere med Linux-kernen 6.x yderligere kontekst; den erstatter dog ikke den databasespecifikke staging-kontrol.

Konfigurer særlige tilfælde sikkert

Ved ustabile rapporteringsforespørgsler bør diagnosticeringen begynde med udførelsesplaner, indekser, sammenkædningsbetingelser og tabelstatistikker. Først når en uønsket plan er indsnævret på en måde, der kan gentages, kan et optimeringstip være en målrettet afgrænsning. Hinten hører til den pågældende forespørgsel og bør indgå i en dokumenteret gennemgang, da datavækst eller ændrede statistikker senere kan ændre dens virkning.

Læseforespørgsler er velegnede til en risikofri statusopgørelse. Udfør dem med en konto, der kun har de nødvendige læserettigheder; de ændrer hverken data, rettigheder eller serverkonfigurationen. Resultaterne viser den faktisk tilsluttede databaseserver og hjælper med at verificere antagelser fra implementeringsdokumentationen.

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

I en proxy-arkitektur er SET SESSION AUTHORIZATION ikke et komforttræk, men en ændring af sikkerhedsmodellen. Skift af session kræver den pågældende rettighed SET USER og er ikke tilgængelig i transaktioner, forberedte sætninger eller gemte procedurer.

Understøttede MaxScale-versioner kan bruge service-loginoplysninger til backend-forbindelsen og derefter skifte til klientens identitet. Dette kræver en MariaDB 12- eller nyere backend-server samt rettigheden SET USER kræves til servicekontoen. Denne funktion følger dog ikke automatisk af et MariaDB 12.0-backend alene: Før implementeringen skal den konkrete kombination af MariaDB-server, MaxScale-version og konfiguration kontrolleres.

MaxScale-indstillingen use_service_credentials bestemmer i de relevante versioner, om MaxScale først skal logge ind på backend med de adgangsoplysninger, der er gemt i tjenesten, og derefter skifte til klientidentiteten. Servicekontoen må ikke tildeles yderligere administratorrettigheder ud over de teknisk nødvendige rettigheder. Revision og en dokumenteret nødnedlukning skal passe til forbindelses- og poolingmodellen.

Replikations- og Galera-topologier kræver en separat testvej for failover, rejoin og gendannelse. Indstillingerne for midlertidige tabeller eller håndteringen af identiske server-ID'er må ikke ændres uden kendskab til binlog-formatet, server-ID'et og returstien. En Galera-optimering er desuden ikke et generelt løfte om ydeevne for klynger, da belastningsprofilen og netværkslatensen fortsat spiller en afgørende rolle.

Hvis man vurderer interne tabeller, midlertidige strukturer eller lagringsmotorer i miljøet, bør man betragte den pågældende motors rolle uafhængigt af versionsmigreringen. Artiklen om MariaDB Aria-lagringsmotor i hosting klassificerer sådanne anvendelsesspørgsmål. For beslutningen om opgradering er det dog afgørende, om den konkrete anvendelse og dens driftsprocesser fungerer på samme måde på målversionen.

Sikring af skift mellem sessioner og audit

SET SESSION AUTHORIZATION er en byggesten til bevidst udformede forbindelsesarkitekturer, ikke blot en forenkling af administrationen. Kommandoen giver en autoriseret konto mulighed for at handle under en anden brugers identitet inden for den aktuelle session. Forudsætningen er privilegiet SET USER. Dermed flyttes ansvaret for registrering og identitetskontrol delvist fra de enkelte kundeforbindelser til en kontrolleret platformskomponent.

Dette mønster kan være nyttigt for en proxy, men MariaDB Server og MaxScale forbliver separate produkter med hver deres versionsstyring. Kun MaxScale-versioner, der understøtter brug af service-adgangsoplysninger med efterfølgende identitetsskift, kan levere denne proces. Et MariaDB 12.0-backend udvider ikke automatisk en ældre eller anderledes konfigureret MaxScale-gren med denne funktion.

I en understøttet kombination logger proxyen ind på MariaDB-serveren med servicekontoen og skifter derefter til den anmodede brugeridentitet. Indstillingen use_service_credentials kræver en MariaDB 12- eller nyere backend-server samt SET USER for servicekontoen. Inden implementeringen skal man derfor i fællesskab kontrollere de konkrete versioner af MariaDB og MaxScale, der anvendes, samt konfigurationen og den planlagte godkendelsesmetode.

Servicekontoen er på grund af muligheden for at Identitetsændring er sikkerhedskritisk. Privilegiet SET USER giver ham ikke automatisk vilkårlige globale administratorrettigheder; desuden må han kun tildeles de teknisk nødvendige rettigheder. Ved skift af session kan man blandt andet omgå kontospærring, udløb af adgangskode, autentificering og REQUIRE-SSL-kontrol af målkontoen. Skiftet er desuden ikke tilgængeligt inden for transaktioner, forberedte sætninger eller gemte procedurer.

For hosting med flere kunder betyder det, at kundekonti forbliver logisk adskilte, og at den tilladte udveksling dokumenteres og begrænses. Derudover skal platformen have en nødlukningsfunktion, f.eks. ved at spærre servicekontoen eller fjerne den berørte forbindelsesvej i henhold til en fastlagt procedure for håndtering af hændelser. Hvilken foranstaltning der er passende, skal afstemmes med forbindelsespooling, eksisterende sessioner og konsekvenserne for andre kunder.

I MariaDB 12.0 tilføjer Audit-pluginet oplysninger om vært og port samt den anvendte TLS-version til indgående forbindelser. Disse oplysninger hjælper med bedre at identificere adgang bag NAT, load balancere eller proxyservere. De erstatter dog ikke en pålidelig klassificering, hvis et forudgående system ændrer kildeoplysningerne eller kun videregiver sin egen adresse til databaseserveren.

Træder i kraft Revision Først og fremmest gennem en driftsproces: Logfiler bør indsamles centralt, beskyttes mod uautoriserede ændringer og administreres i henhold til en fastsat opbevaringsperiode. Adgangsrettigheder til indsigt og eksport skal adskilles ligesom ansvaret for alarmering og undersøgelse. Om yderligere logdata har en mærkbar indflydelse på en konkret platforms kapacitet eller ydeevne, kan ikke udledes af versionen uden målinger.

I tilfælde af en sikkerhedshændelse skal operatører kunne spore, hvilken identitet proxyen har angivet, via hvilken adgang sessionen blev oprettet, og hvilke auditdata der foreligger herom. Regelmæssige, dokumenterede kontroller af nedlukningen og logfilernes tilgængelighed er vigtigere end en så omfattende logføring som muligt. Især må en auditlog ikke erstatte et rettighedskoncept, transportkryptering eller sikker adgangskodestyring.

Overvåg driften efter opgraderingen

Efter en MariaDB-opdatering indledes en overvågningsfase; der foretages ingen automatisk optimering. Først skal man afgøre, om Serverstart mislykkes, et program ikke længere kan oprette forbindelse, eller en replikeringssti afviger. Disse fejl har forskellige årsager og kræver separate løsninger i stedet for at blive løst med generelle konfigurationsændringer.

Startfejl indsnævres ved hjælp af serverfejlloggen og en versioneret oversigt over de konfigurationsfiler, der rent faktisk er indlæst. I MariaDB 12.0 blev der for eksempel big_tables og storage_engine fjernet. Sådanne poster må ikke forblive uændrede i my.cnf eller integrerede konfigurationsfragmenter; den dokumenterede variabelreference og startmeddelelsen viser, hvilken indstilling der konkret er tale om.

Ved forbindelsesmoduler og plugins skal installerede pakker, indlæste modulversioner og applikationens fejlmeddelelse registreres samlet. Valget af et repository alene garanterer ikke en kompatibel installation: Ved en specifik serverversion skal server-, klient-, delte og fælles pakker planlægges med samme version. Hvilke navne og versioner der er tilgængelige, afhænger af det anvendte repository og operativsystemet.

Applikationsfejl kan bedst undersøges ved hjælp af et reproducerbart, så lille som muligt SQL-eksempel og de tilhørende klient- eller connector-logfiler. En gennemgang af den aktuelle situation kan foretages med SELECT VERSION(); begynde. Resultatet identificerer den database-server, der svarer, men beviser hverken, at en ORM er kompatibel, eller at en applikationskonfiguration fungerer korrekt.

Med hensyn til replikering skal den dokumenterede replikeringsstatus, binlog-formatet, server-ID’er samt hændelser vedrørende failover og rejoin indgå i diagnosticeringsrapporten. Midlertidige tabeller, topologien og ændringer i replikeringsindstillingerne skal kontrolleres separat. En vellykket lokal skrivetest er ikke tilstrækkelig til at påvise konsistens og forventet adfærd på alle involverede instanser.

Server- og revisionslogfiler, konfigurationsoversigter, versionsforespørgsler og reproducerbare forespørgselsforsøg udgør tilsammen en en forståelig fejlkæde. Den gør det også lettere at afgøre, om en genopretningsplan skal iværksættes. Et højere versionsnummer medfører hverken en bestemt ydeevneforbedring eller en universel optimering; ændringer af parametre for caching, optimering eller replikering kræver en konkret hypotese og en målbar effekt.

At afgøre slutresultatet strategisk

Det rette mål afhænger af platformens formål og driftsmodel, ikke af den samlede betegnelse MariaDB 12. For klassiske databaser til CMS, webshops og webapplikationer har opgraderingssikkerhed, klar adskillelse af klienter og en pålidelig gendannelsesproces som regel højere prioritet end enkelte nye SQL-funktioner. Nye GIS-funktioner eller rutiner er ikke i sig selv en grund til migration, hvis applikationerne ikke bruger dem.

Komplekse rapporteringsapplikationer kan drage fordel af Optimizer-hints, hvis en analyse klart afgrænser en uønsket eksekveringsplan. Forud for dette skal indekser, sammenkædningsbetingelser, datafordeling og statistikker kontrolleres. Et tip er en målrettet binding til en planbeslutning og kan blive uhensigtsmæssigt efter datavækst eller ændrede statistikker; det skal derfor indgå i applikationsdokumentationen sammen med forespørgsel, begrundelse og tilbagekaldelseskriterium.

Proxy- og klyngemiljøer kræver en særskilt testprocedure. For en proxy vedrører denne især servicekontos autorisationsmodel, skift mellem sessioner og muligheden for revision. For replikering eller Galera omfatter dette failover, rejoin, gendannelse og opførslen af midlertidige tabeller. En vellykket opgradering af en enkelt instans er ikke bevis på, at disse processer fungerer korrekt i hele topologien.

Die Udgivelsesstrategi skal skelne mellem innovationsudgivelser og LTS-udgivelser. MariaDB beskriver innovationsudgivelser som rullende udgivelser, der som regel ikke vedligeholdes løbende med patch-versioner efter GA; den planlagte vej fører videre til den næste rullende serie. LTS-udgivelser vedligeholdes derimod i tre år fra GA. Dette medfører ikke en generel forpligtelse til pakke- eller kontraktbaseret support af et konkret hostingmiljø.

Inden beslutningen træffes, skal man derfor samlet vurdere distributionens pakke- og supporttilbud, testet applikationskompatibilitet, en dokumenteret gendannelse, sikkerhedsmodellen og de løbende driftsomkostninger. MariaDB og MySQL er ikke udskiftelige på trods af mange fælles SQL-mønstre: MariaDB anvender sin egen GTID-model og understøtter for eksempel ikke MySQLs SET PERSIST. Migrationsantagelser fra et MySQL-miljø skal derfor kontrolleres.

For serie 12.0 er 12.0.2 dokumenteret som en stabil GA-version, mens 12.0.0 var en preview-version og 12.0.1 en release candidate. Denne klassificering beskriver den daværende modenhedsstatus, men erstatter ikke en aktuel beslutning om frigivelse. Umiddelbart før udrulning eller offentliggørelse skal operatører på ny kontrollere den tilbudte pakkeversion, operativsystemunderstøttelse og aktuelle udgivelsesklassificering i forhold til producentens oplysninger.

Det afgørende er derfor den konkret testede platformstilstand med dens afhængigheder og driftsregler. En kontrolleret udrulning er berettiget, hvis kompatibilitet, tilbageførsel og ansvarsfordeling er dokumenterbart forberedt. Mangler disse forudsætninger, er navnet MariaDB 12 ikke et argument for at påtage sig risici i shared hosting eller i et forretningskritisk databasemiljø.