MariaDB 12.0: Funktioner, uppdateringsrisker och hostingstrategi

Korrekt klassificering av MariaDB 12.0

Beteckningen „MariaDB 12“ avser inte någon enhetlig produktversion som underhålls kontinuerligt. För konkreta tekniska uppgifter gäller här den löpande serien MariaDB 12.0 avses. Inom denna serie representerar utgåvorna olika mognadsgrader: 12.0.0 släpptes den 26 mars 2025 som en förhandsversion, 12.0.1 den 5 juni 2025 som release candidate och 12.0.2 den 7 augusti 2025 som en stabil GA-release.

Preview och Release Candidate är avsedda för testning och ska inte likställas med en stabil plattformsversion. Att 12.0.2 dokumenteras som Stable respektive GA beskriver däremot mognadsgraden just för den här versionen. Detta innebär varken att varje installation omedelbart bör uppgraderas, eller att senare versioner automatiskt kommer att ha samma egenskaper, paket eller driftsgränser.

Även senare versioner som 12.1, 12.2 eller 12.3 måste betraktas separat. Funktioner, felkorrigeringar eller ändrade standardvärden från sådana serier utgör inte något bevis för MariaDB 12.0. Detta gäller även utvecklingsgrenar: Ett meddelande eller dokumentation där ersätter inte någon information om den publicerade versionen på community-servern.

Innan en lansering måste plattformen därför återigen jämföras med den faktiskt planerade paketstatusen. Man bör särskilt kontrollera den tillgängliga serverserien, att klient- och tilläggspaketen är kompatibla med varandra, stödet från den använda operativsystemversionen samt den aktuella release-klassificeringen. Innehållet i arkivet och distributionspaketen kan avvika från den allmänna produktbeteckningen.

Skillnaden mellan Rolling Release och LTS

För värdplattformar är det inte bara versionsnumret som är relevant, utan även den underliggande Lanseringsmodell. MariaDB skiljer mellan innovationsutgåvor och LTS-utgåvor. Innovationsutgåvorna introducerar nya funktioner med korta mellanrum och övergår vanligtvis till nästa rullande serie efter att de nått GA-status. LTS-utgåvorna underhålls däremot, enligt tillverkaren, i tre år efter GA.

En stabil GA-version besvarar alltså endast frågan om just denna version har släppts som stabil. Den ger inget generellt svar på hur länge säkerhetsuppdateringar kommer att finnas tillgängliga, om en distributör fortsätter att leverera paket eller om en befintlig kundbas kan fortsätta använda serien utan att behöva migrera. Dessa punkter beror på avtalet, distributionen och den aktuella översikten över utgåvor.

En innovationsserie kan vara lämplig om en plattform vill införa en funktion som det finns ett tydligt behov av i ett tidigt skede och kan testa de berörda applikationerna, kopplingarna och driftsprocesserna isolerat. För detta måste teamen planera för att snabbt gå vidare med den planerade uppgraderingsvägen. Särskilt när det gäller lösningar med flera kunder ökar detta arbetsinsatsen för godkännanden, kommunikation och återfallsprocedurer.

En LTS-målställning passar bättre för standardiserade plattformar med många klassiska applikationer, när planerbara underhållsfönster och en stabil mjukvaruversion under en längre tid är viktigare än enskilda nya funktioner. Detta är ingen regel som utesluter innovationslanseringar: Det avgörande är om nyttan av en funktion motiverar de extra testerna och den förväntade övergången till nästa serie.

Valet bör därför åtminstone ta hänsyn till funktionsbehov, aktuell paket- och supportstatus, testad applikationskompatibilitet, återställningsbarhet och personalrelaterade driftskostnader. Vid en nyinstallation räcker det inte att betrakta „MariaDB 12“ som det modernaste alternativet. Plattformen gör ett medvetet val mellan kortsiktig användning av funktioner och en långsiktigt standardiserad databasnivå.

Utvärdera nya funktioner med begränsningar

MariaDB 12.0 kompletterar Tips för optimeringsverktyget för att på ett mer målinriktat sätt påverka exekveringsplaner, till exempel när det gäller join-sekvenser, intervalloptimering eller vissa join-algoritmer. Utökningarna gäller dessutom nedåtordnade indexkomponenter vid Loose Index Scan och Index Condition Pushdown. För hosting är detta framför allt ett diagnostikverktyg för enskilda problematiska frågor, inte en ersättning för lämpliga index, korrekta join-villkor och aktuella tabellstatistikuppgifter.

En riktlinje kan begränsa en oönskad strategi, men kan i sig ha negativa effekter när datamängden ökar eller statistiken förändras. Den hör därför hemma i en reproducerbar analys av den berörda applikationen och inte som en övergripande riktlinje i databasserver. För typiska CMS- och webbshoppdatabaser är enbart förekomsten av sådana tips inte ett tillräckligt övertygande skäl för att uppdatera till MariaDB.

Vid en granskning loggar granskningsplugin i version 12.0 dessutom värd och port för inkommande anslutningar samt vilken TLS-version som används. För åtkomst bakom proxyservrar, NAT eller lastbalanserare kan detta förbättra den forensiska tilldelningen. Fördelen uppstår dock först genom en central, åtkomstskyddad loggsamling och fastställda regler för lagring; ytterligare loggdata måste passa in i kapacitets- och dataskyddsplaneringen.

När det gäller kryptering finns stöd för SHA-2 i file_key_management.so och ssl_passphrase Komponenterna är klara. Replikationsmiljöerna får alternativ för tillfälliga tabeller samt en variabel för hantering av händelser med eget server-ID. Dessutom introducerar version 12.0 bland annat SYS_REFCURSOR, en markörbegränsning per session och GIS-funktioner som validering, förenkling och Geohash-konvertering. Dessa verktyg är endast till hjälp i lämpliga tillämpningar och topologier.

MariaDB Server, MaxScale och Galera förblir separata komponenter: MaxScale har egna versioner och konfigurationer, medan Galera-relaterade ändringar enbart berör kluster. På samma sätt innebär MySQL-kompatibilitet inte att de är utbytbara utan ytterligare kontroll. MariaDB använder en egen GTID-modell och stöder till exempel inte MySQL:s SET PERSIST. Nya GIS-funktioner kan vara till hjälp för geodataprogram som bygger på MySQL 8, men utgör i regel inte någon anledning att uppgradera vanliga webbdatabaser.

Jämföra versionsstatus och funktioner

För plattformsdriften är den specifika versionen inom serien avgörande. MariaDB 12.0.0 var en förhandsversion, 12.0.1 en release candidate och först 12.0.2 är dokumenterad som stabil eller GA. Dessa statusar indikerar olika mognadsgrader; de säger ingenting om huruvida serien är lämplig för en viss hostinglansering, ett operativsystem eller ett supportavtal.

Nya funktioner är särskilt användbara när de löser ett konkret driftsproblem. Tips för optimeringsverktyget kan till exempel begränsa en oönskad exekveringsplan för en enskild komplex fråga. De ersätter varken lämpliga index, korrekta join-villkor eller aktuella statistiska uppgifter och bör inte användas som en global standard för kundapplikationer.

De ytterligare granskningsfälten kan registrera värd, port och vilken TLS-version som används för en inkommande anslutning. Nyckelalternativet ssl_passphrase Däremot motiverar de utökade GIS- eller markörfunktionerna inte ett generellt versionsbyte. De ger endast fördelar i tillämpningar där arkitekturen, datamodellen och säkerhetskraven faktiskt kräver dessa funktioner.

Förbereda en kontrollerad uppdatering av MariaDB

En MariaDB-uppdatering inom managed eller shared hosting inleds med en inventering: instanser, databaser, kopplingar, tillägg, konfigurationsfiler, replikeringsvägar och berörda applikationer måste kartläggas. Därefter följer en testmiljö som återspeglar produktionsdata och konfiguration endast enligt de tillåtna säkerhetskraven. På så sätt kan startproblem och SQL-avvikelser upptäckas innan flera kunder drabbas.

Innan varje begränsad driftsättning krävs en fullständig säkerhetskopia och en dokumenterad återställningsprocess. Det är inte bara avgörande att säkerhetskopiorna finns: De ansvariga måste kontrollera om det går att återställa ett konsekvent datatillstånd som kan användas av applikationerna. Därefter kontrollerar de inloggningar, skrivoperationer, bakgrundsjobb och typiska kundvägar som Regressionstestning. Det konkreta tillvägagångssättet beror på vilken säkerhetsmetod som används och på plattformens arkitektur.

En återgångsplan fastställer vem som beslutar vilka datatillstånd som är giltiga och hur applikationer återgår till det föregående konsistenta tillståndet vid ett avbrott. Detta är redaktionell driftspraxis, inte en egenskap hos en viss MariaDB-version. Replikering, övervakning och failover måste därför testas i respektive staging-topologi, istället för att man utgår från att de fungerar utifrån en lyckad uppdatering av en enskild instans.

MariaDB 12.0 tar bort systemvariablerna big_tables, large_page_size och storage_engine. Befintliga poster måste därför anges i my.cnf och alla inblandade konfigurationsfragment måste hittas och utvärderas för måltillståndet. Rensningen ska ske före paketuppdateringen; vid large_page_size Man måste dessutom skilja mellan den borttagna MariaDB-variabeln och en HugePages-konfiguration i operativsystemet som är oberoende av denna.

Även paketplaneringen förtjänar ett eget steg: Ett repository kan innehålla flera MariaDB-versioner, och tillhörande server-, klient-, delade och gemensamma paket bör ha samma version. Operativsystemets version och paketkällorna ingår i godkännandet. För beroenden på värdnivå ger artikeln om Relevanta nyheter för webbservrar som kör Linux-kärnan 6.x ytterligare sammanhang; den ersätter dock inte den databasspecifika staging-kontrollen.

Konfigurera specialfall på ett säkert sätt

Vid instabila rapporteringsfrågor bör felsökningen inledas med att granska exekveringsplaner, index, join-villkor och tabellstatistik. Först när en oönskad exekveringsplan har kunnat avgränsas på ett reproducerbart sätt kan en optimeringshint utgöra en målinriktad begränsning. Tipset hör till den aktuella frågan och bör ingå i en dokumenterad granskning, eftersom datatillväxt eller ändrade statistiska uppgifter senare kan påverka dess effekt.

Läsningsfrågor är lämpliga för en riskfri inventering. Utför dem med ett konto som endast har de behörigheter som krävs för detta; de ändrar varken data, behörigheter eller serverkonfigurationen. Resultaten visar vilken databasserver som faktiskt är ansluten och hjälper till att verifiera antaganden från driftsättningsdokumentationen.

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

I en proxyarkitektur är SET SESSION AUTHORIZATION inte en bekvämlighetsfunktion, utan ett ingrepp i säkerhetsmodellen. För att byta session krävs behörigheten SET USER och är inte tillgängligt inom transaktioner, förberedda satser eller lagrade procedurer.

Kompatibla versioner av MaxScale kan använda tjänstens inloggningsuppgifter för backend-anslutningen och därefter byta till klientens identitet. För detta krävs en backend-server med MariaDB 12 eller senare samt behörigheten SET USER krävs för servicekontot. Denna funktion följer dock inte automatiskt av enbart ett MariaDB 12.0-backend: Innan driftsättningen måste den specifika kombinationen av MariaDB-server, MaxScale-version och konfiguration kontrolleras.

MaxScale-inställningen use_service_credentials styr, i lämpliga versioner, om MaxScale först ska logga in på backend med de inloggningsuppgifter som lagrats i tjänsten och därefter byta till klientidentiteten. Servicekontot får inte tilldelas några ytterligare administratörsrättigheter utöver de tekniskt nödvändiga rättigheterna. Revisionsloggning och en dokumenterad nödavstängning måste vara anpassade till anslutnings- och poolningsmodellen.

Replikations- och Galera-topologier kräver en egen testväg för failover, återanslutning och återställning. Inställningarna för temporära tabeller eller hanteringen av identiska server-ID:n får inte ändras utan kunskap om binlog-formatet, server-ID:t och återgångsvägen. En Galera-optimering är dessutom inget generellt prestandalöfte för kluster, eftersom belastningsprofilen och nätverksfördröjningen fortfarande är avgörande.

Den som utvärderar interna tabeller, tillfälliga strukturer eller lagringsmotorer i miljön bör betrakta den respektive motorns roll separat från versionsmigreringen. Artikeln om MariaDB Aria-lagringsmotor vid webbhotell klassificerar sådana driftsfrågor. För beslutet om uppgradering är det dock avgörande om den konkreta tillämpningen och dess driftsprocesser fungerar på ett reproducerbart sätt i målversionen.

Säkra bytet av session och granskningen

SET SESSION AUTHORIZATION är en byggsten för medvetet utformade anslutningsarkitekturer, inte bara ett hjälpmedel för administrationen. Kommandot tillåter ett behörigt konto att agera under en annan användares identitet inom den aktuella sessionen. En förutsättning är behörigheten SET USER. På så sätt flyttas ansvaret för inloggning och identitetskontroll delvis från enskilda kundanslutningar till en kontrollerad plattformskomponent.

Denna modell kan vara lämplig för en proxy, men MariaDB Server och MaxScale förblir separata produkter med egna versionsnummer. Endast MaxScale-versioner som stöder användning av tjänsteinloggningsuppgifter med efterföljande identitetsbyte kan tillhandahålla denna process. Ett MariaDB 12.0-backend utökar inte automatiskt en äldre eller annorlunda konfigurerad MaxScale-gren med denna funktion.

I en stödd kombination loggar proxyn in på MariaDB-servern med servicekontot och byter därefter till den begärda användaridentiteten. Inställningen use_service_credentials kräver en MariaDB 12 eller senare som backend-server samt SET USER för servicekontot. Innan införandet måste därför de specifika versionerna av MariaDB och MaxScale som används, konfigurationen och den planerade autentiseringsmetoden granskas gemensamt.

Servicekontot är på grund av möjligheten att Identitetsbyte utgör en säkerhetsrisk. Privilegiet SET USER ger honom inte automatiskt godtyckliga globala administratörsrättigheter; dessutom får han endast tilldelas de behörigheter som är tekniskt nödvändiga. Vid sessionsbyte kan bland annat kontospärr, lösenordsutgång, autentisering och REQUIRE-SSL-kontroll av målkontot kringgås. Byte är dessutom inte tillgängligt inom transaktioner, förberedda satser eller lagrade procedurer.

För multiklient-hosting innebär detta att kundkonton förblir logiskt åtskilda och att den tillåtna kopplingskretsen dokumenteras och begränsas. Dessutom måste plattformen ha en nödavstängningsfunktion, till exempel genom att spärra servicekontot eller ta bort den berörda anslutningsvägen enligt ett fastställt incidentförfarande. Vilken åtgärd som är lämplig måste avgöras med hänsyn till anslutningspooling, befintliga sessioner och konsekvenserna för andra kunder.

I MariaDB 12.0 kompletterar Audit-pluginet inkommande anslutningar med värd och port samt vilken TLS-version som används. Dessa uppgifter hjälper till att bättre identifiera åtkomst bakom NAT, lastbalanserare eller proxyservrar. De ersätter dock inte en tillförlitlig identifiering om ett uppströms system ändrar källinformationen eller endast vidarebefordrar sin egen adress till databasservern.

Träder i kraft Revision först genom en driftsprocess: Loggar bör samlas in centralt, skyddas mot obehöriga ändringar och hanteras enligt en fastställd lagringstid. Åtkomsträttigheter för insyn och export ska åtskiljas, liksom ansvaret för larm och utredning. Om ytterligare loggdata märkbart påverkar kapaciteten eller prestandan hos en specifik plattform går det inte att avgöra utifrån versionen utan mätning.

Vid en säkerhetsincident bör operatörerna kunna spåra vilken identitet proxyservern har angett, via vilken åtkomst sessionen uppstod och vilka granskningsdata som finns tillgängliga i detta sammanhang. Regelbundna, dokumenterade kontroller av avstängningen och loggarnas tillgänglighet är viktigare än en så omfattande loggning som möjligt. Framför allt får en revisionslogg inte ersätta ett behörighetskoncept, transportkryptering eller säker hantering av hemlig information.

Övervaka driften efter uppgraderingen

Efter en MariaDB-uppdatering inleds en övervakningsfas, ingen automatisk optimering sker. Först måste man avgöra om Serverstart misslyckas, en applikation inte längre kan upprätta en anslutning eller en replikeringsväg avviker. Dessa fel har olika orsaker och kräver separata åtgärder, istället för att hanteras med generella konfigurationsändringar.

Startfel lokaliseras med hjälp av serverfelprotokollet och en versionshanterad förteckning över de konfigurationsfiler som faktiskt har laddats. I MariaDB 12.0 har till exempel big_tables och storage_engine borttagna. Sådana poster får inte lämnas oförändrade i my.cnf eller inbäddade konfigurationsfragment; den dokumenterade variabelreferensen och startmeddelandet visar vilken inställning som konkret berörs.

När det gäller anslutningar och tillägg ska installerade paket, laddade modulversioner och applikationens felmeddelande dokumenteras tillsammans. Valet av arkiv i sig garanterar inte en kompatibel installation: vid en specifik serverversion måste server-, klient-, delade och gemensamma paket planeras med samma version. Vilka namn och versioner som är tillgängliga beror på vilket arkiv och vilket operativsystem som används.

Applikationsfel kan bäst utredas med hjälp av ett reproducerbart, så litet SQL-fall som möjligt och tillhörande klient- respektive connector-loggar. En läsbar översikt kan skapas med SELECT VERSION(); börja. Resultatet identifierar den databasserver som svarar, men bevisar varken att ett ORM är kompatibelt eller att en applikationskonfiguration fungerar korrekt.

När det gäller replikering ska den dokumenterade replikeringsstatusen, binlog-formatet, server-ID:n samt händelser relaterade till failover och rejoin ingå i diagnosfilen. Tillfälliga tabeller, topologin och ändringar av replikeringsinställningarna ska kontrolleras separat. Ett lyckat lokalt skrivtest räcker inte för att bekräfta konsistens och förväntat beteende på alla berörda instanser.

Server- och revisionsloggar, konfigurationsinventering, versionsförfrågningar och reproducerbara förfrågningstester utgör tillsammans en en begriplig kedja av fel. Den underlättar också beslutet om huruvida en återfallplan måste aktiveras. Ett högre versionsnummer medför varken någon specifik prestandapåverkan eller någon universell finjustering; ändringar av parametrar för lagring, optimering eller replikering kräver en konkret hypotes och en verifierbar effekt.

Att strategiskt avgöra slutresultatet

Den lämpliga målversionen avgörs av plattformens uppgift och driftsmodell, inte av den samlade beteckningen MariaDB 12. För traditionella databaser för CMS, webbutiker och webbapplikationer har uppgraderingssäkerhet, tydlig klientseparation och en robust återställningsväg oftast högre prioritet än enskilda nya SQL-funktioner. Nya GIS-funktioner eller rutiner utgör inte i sig ett skäl för migrering om applikationerna inte använder dem.

Komplexa rapporteringsapplikationer kan dra nytta av Optimizer-Hints om en analys tydligt avgränsar en oönskad exekveringsplan. Innan detta bör index, join-villkor, datadistribution och statistik kontrolleras. Ett tips är en målinriktad koppling till ett planbeslut och kan bli olämpligt efter datatillväxt eller ändrade statistiska uppgifter; det bör därför ingå i applikationsdokumentationen tillsammans med frågan, motiveringen och kriterierna för att återta det.

Proxy- och klustermiljöer kräver en egen testväg. För en proxy gäller detta särskilt servicekontots behörighetsmodell, sessionsbyten och möjligheten till granskning. För replikering eller Galera ingår failover, återanslutning, återställning och beteendet hos temporära tabeller. En lyckad uppgradering av en enskild instans bevisar inte att dessa processer fungerar korrekt i hela topologin.

Die Lanseringsstrategi måste skilja mellan innovationsutgåvor och LTS-utgåvor. MariaDB beskriver innovationsutgåvor som rullande utgåvor som efter GA i regel inte underhålls kontinuerligt med patch-versioner; den planerade vägen leder till nästa rullande serie. LTS-utgåvor underhålls däremot i tre år från och med GA. Detta innebär inte något generellt åtagande om paket- eller avtalsbaserad support för en specifik hostingmiljö.

Innan beslutet fattas bör man därför sammantaget utvärdera distributionens paket- och supportutbud, testad kompatibilitet med applikationer, en beprövad återställningsfunktion, säkerhetsmodellen samt de löpande driftskostnaderna. MariaDB och MySQL är inte utbytbara trots många gemensamma SQL-mönster: MariaDB använder en egen GTID-modell och stöder till exempel inte MySQLs SET PERSIST. Migrationsantaganden från en MySQL-miljö måste därför kontrolleras.

För serie 12.0 är 12.0.2 dokumenterad som en stabil GA-version, medan 12.0.0 var en förhandsversion och 12.0.1 en release candidate. Denna klassificering beskriver mognadsgraden vid den tidpunkten, men ersätter inte ett aktuellt beslut om lansering. Omedelbart före lansering eller publicering måste operatörerna återigen kontrollera den erbjudna paketversionen, operativsystemstödet och den aktuella release-klassificeringen mot tillverkarens information.

Avgörande är alltså den konkret granskade plattformsversionen med dess beroenden och driftsregler. En kontrollerad utrullning är motiverad om kompatibilitet, återgång till tidigare versioner och ansvarsfördelning är bevisligen förberedda. Om dessa förutsättningar saknas är namnet MariaDB 12 inget argument för att ta på sig risker inom delad hosting eller i en affärskritisk databasmiljö.