Analysera och tolka MariaDB:s fellogg på rätt sätt

Felprotokollets syfte och begränsningar

Das MariaDB:s fellogg är serverprocessens driftslogg. Den registrerar framför allt start- och avstängningsprocesser, kritiska serverhändelser samt uppgifter som kan tyda på problem med tabeller eller lagringsmotorn. Loggen är alltid aktiv, men utdatakanalen kan konfigureras på olika sätt.

Där visas till exempel misslyckade initialiseringar av plugins, oläsbara filer, åtkomstnekanden eller meddelanden om anslutningar. En rad med „Access denied“ bevisar dock i första hand endast att en inloggning med de överförda uppgifterna inte accepterades. Om det beror på lösenordet, användar-värd-kopplingen, autentiseringsmetoden eller den anropande applikationen framgår först av sammanhanget.

Felprotokollet är dessutom inte ett fullständigt arkiv över alla SQL-fel i en applikation. För detta finns det ett separat SQL_ERROR_LOG-plugin; det kan skriva eventuella SQL-fel till en egen fil och tar även hänsyn till fel som en villkorshanterare bearbetar innan de når klienten. Pluginet är inte installerat som standard. Dess poster kan innehålla användar-, värd-, databas- och SQL-information, varför åtkomstskydd och dataminimering bör fastställas innan det tas i bruk.

För Felsökning av MySQL Därför är den kronologiska ordningen viktigare än en enskild avslutande rad. Säkra först ett sammanhängande utdrag före och efter händelsen. Om ett konkret felmeddelande följs av flera efterföljande poster och slutligen ett avbrott, ligger den första relevanta avvikelsen ofta närmare orsaken än det sista synliga felet. Även tidpunkt, observerade symptom och samtidiga ändringar i applikationen eller systemet ingår i utvärderingen.

Fastställa lagringsplatser på ett säkert sätt

En saknad fil med filändelsen .err betyder inte att MariaDB inte har loggat något. Felprotokollet kan skrivas till en fil, till standardfelutmatningen eller via Syslog till systemd-journalen; i Windows tillkommer dessutom händelseloggen. Vilket alternativ som är aktivt beror på serverinställningar, paketkonfiguration och startmekanismen för den specifika installationen.

Alternativet log_error anger målet vid filbaserad utmatning. Ett relativt filnamn tolkas relativt till datakatalogen, medan en absolut sökväg är oberoende av denna. Om inget namn uttryckligen anges beskriver dokumentationen en fil enligt mönstret värdnamn plus .err i datakatalogen. Man bör dock inte dra några slutsatser om en fast sökväg utifrån detta: Kontrollera alltid den faktiska konfigurationen.

Följande kommandon läser endast in inställningar från inställningsfiler. De är därför en bra utgångspunkt för log_error, men återspeglar inte nödvändigtvis den fullständiga konfigurationen för den aktiva processen. Ytterligare startparametrar samt systemd-unit- eller drop-in-överskrivningar kan komplettera eller ändra värden och måste kontrolleras separat.

I den aktuella MariaDB-dokumentationen kallas serverprocessen mariadbd; mysqld kan, beroende på installationen, fortfarande förekomma som kompatibilitetsnamn. De båda benämningarna bör därför inte likställas utan att ta hänsyn till versions- och installationskontexten. Kommandona ändrar varken tjänsten eller data.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

Enligt dokumentationen är det andra kommandot avsett för MariaDB 10.11 och senare; det tredje är relevant för installationer med den äldre programbeteckningen. Om du inte hittar någon tydlig filangivelse i optionsfilerna bör du kontrollera Journal eller Syslog samt parametrarna för den tjänst som faktiskt har startats, istället för att skapa en antagen loggväg. Detta förhindrar att diagnostik och körningskonfiguration skiljer sig åt.

Att tolka radformat och sammanhang korrekt

I filbaserade felloggar i moderna versioner av MariaDB från och med 10.1.5 följer en rad i princip mönstret tidsstämpel, tråd-ID, nivå och meddelande. Den Tidsstämpel klassificerar händelsen, tråd-ID:t kan koppla den till andra poster för samma serveranslutning, och nivån beskriver typen av meddelande. Först i kombination med dessa fält ger meddelandet en tillförlitlig utgångspunkt för felsökningen.

I MariaDB upp till och med version 10.1.4 är tidsformatet kortare och presentationen skiljer sig från det nyare schemat. En parser eller en sökfunktion som förväntar sig fasta fältpositioner enligt det aktuella formatet kan därför tolka äldre loggar felaktigt. Dessutom kan externa SST-skript i Galera-miljöer skriva rader där tråd-ID och nivå saknas. Sådana specialrader är inte automatiskt skadade loggdata.

Följande utdrag är endast ett schematiskt exempel på läsriktningen för en misslyckad startsekvens. Det bygger inte på något verkligt fall och ersätter varken den fullständiga startutmatningen eller kontrollen av de giltiga alternativen. Det avgörande är att konfigurationsavvikelsen föregår det avslutande avbrottsmeddelandet.

2026-09-23 08:14:02 0 [Note] Starting MariaDB
2026-09-23 08:14:02 0 [ERROR] unknown variable 'example_option=1'
2026-09-23 08:14:02 0 [ERROR] Aborting

Här är unknown variable Det första som bör undersökas: Alternativet kan vara felstavat, inte tillgängligt i den här versionen eller placerat i fel konfigurationsfil. Aborting beskriver däremot slutpunkten för startsekvensen. Sök därför bakåt till det första relevanta meddelandet och notera sedan de efterföljande raderna. På så sätt skiljer du mellan den troliga orsaken, serverns reaktion och de synliga effekterna av databasfel tydligt åtskilda från varandra.

Inledande granskning utan riskfyllda ändringar

Innan du tolkar ett meddelande eller ändrar inställningarna, säkerhetskopiera Driftskontext: den fullständiga MariaDB-versionen, inklusive eventuella paket- eller distributionstillägg, operativsystem, startmekanism, tidpunkt och synliga symptom. En omstart, ett misslyckat inloggningsförsök eller ett avbrott i replikeringen är olika händelser. Utan dessa uppgifter går det inte att göra en tillförlitlig bedömning av samma loggrad.

Kopiera inte heller en enskild träff, utan ett sammanhängande avsnitt före och efter den första märkbara händelsen. Notera när problemet uppstod för användare eller applikationer och om det samtidigt skedde ändringar i konfigurationen, driftsättningen eller nätverket. På så sätt kan utlösande faktorer, följdfel och normal start- eller avstängningssekvens särskiljas tidsmässigt från varandra.

Följande kommandon läser endast in uppgifter från inställningsfiler och ändrar varken tjänsten eller data. De är särskilt användbara för att läsa av en inställning som har angetts där log_error att hitta. De visar dock inte automatiskt alla värden som tjänsten faktiskt startades med: Ytterligare startparametrar, systemd-enhetsfiler och drop-ins måste du kontrollera separat.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

Från och med MariaDB 10.11 dokumenterar MariaDB my_print_defaults --mariadbd för denna sökning. Namnet mariadbd avser dagens serverprocess; mysqld finns kvar i många installationer som en äldre benämning eller för kompatibilitetsändamål. Betrakta därför inte de båda namnen som bevis på att det rör sig om samma specifika serverversion eller samma tjänstnamn.

Om loggen finns i systemd-Journalen, avgränsa tidsintervallet med hjälp av det enhetsnamn som har kontrollerats på systemet. Kontrollera vid behov även enhetsfilen och eventuella drop-ins så att ytterligare startparametrar inte förbises. Komplettera sedan utdraget med applikationsloggen för samma tidsperiod, om symptomet uppträder i en applikation.

journalctl -u <geprüfte-mariadb-unit> --since "2026-09-23 08:00" --until "2026-09-23 09:00"

Klassificera nivåer och startfel

Markeringar ger struktur åt MariaDB:s fellogg, men ersätter inte en orsaksanalys. En Allvarlighetsgrad beskriver hur en rad klassificeras, men inte automatiskt skadans omfattning eller hur brådskande ärendet är. Särskilt vid ett startproblem är ordningen avgörande: Ett tidigare konkret felmeddelande förklarar ofta ett senare Aborting, medan anvisningar före detta även kan beskriva vanlig initialisering.

Om MariaDB inte startar, avgränsa först den senaste startsekvensen i loggen och läs sedan baklänges. Leta särskilt efter unknown variable, saknade eller oläsbara filer, behörighetsproblem och fel vid initialiseringen av plugin-moduler. MariaDB hänvisar till felloggen som den främsta källan vid misslyckade startförsök; vid manuell start kan orsaken dessutom visas på konsolen.

En Konfigurationsfel gäller oftast en okänd inställning, stavning eller ett felaktigt värde i en inläst fil. Kontrollera då först de aktiva inställningarna och versionsmappningen, istället för att röra datamängderna. Ett fel vid öppning av en datafil eller ett InnoDB-meddelande kan däremot gälla behörigheter, sökvägar, lagringsutrymme eller datatillstånd och kräver en betydligt mer försiktig bedömning.

Ändra inte flera parametrar samtidigt för att tvinga fram en omstart. Spara loggutdraget och notera vilken ändring som föregick felet. Först när det första relevanta meddelandet har kopplats till en kontrollerad inställning eller resurs går det att planera en målinriktad och spårbar korrigering.

Diagnostisk bedömning av vanliga symtom

Återkommande formuleringar förkortar sökningen, men ger sällan en diagnos på egen hand. Koppla varje meddelande till ett tidsfönster, den berörda värden eller tråden och det observerade symptomet. Tabellen anger medvetet endast diagnostiska nästa steg: den förhindrar att man förhastat drar slutsatsen att orsaken ligger i databasservern utifrån en hänvisning till anslutningar, filer eller replikering.

Med Åtkomst nekad Det är först och främst avgörande för vilken användare och vilken klientvärd inloggningen avvisades. Kontrollera den använda applikationskonfigurationen och tidpunkten, inte bara lösenordet i sig. Meddelandet kan bero på felaktiga inloggningsuppgifter, en avvikande värdreferens eller felaktig autentisering; det är inte ett tecken på att databasen är skadad.

En Avbruten anslutning kan bero på en tidsgräns för applikationen, en avbruten nätverksförbindelse, en proxy eller felaktig paketkommunikation. Jämför klientvärd och tråd-ID med applikationsloggen. Använd globala värden istället för sessionsrelaterade värden för räknare; annars kan en nystartad session visa missvisande låga värden.

SHOW GLOBAL STATUS LIKE 'Aborted%';

Sökningen visar räknare, men ingen fullständig orsak och ingen koppling till en enskild klient. Utvärdera därför förändringar över en lämplig tidsperiod tillsammans med loggutdrag. Vid replikerings- eller GTID-meddelanden ska du dessutom dokumentera de efterföljande raderna och kontrollera replikeringsstatusen med hjälp av avsedd statusinformation; enbart raden i felloggen räcker inte för en fullständig replikeringsdiagnos.

Utvärdera InnoDB-återställning utan risk för dataförlust

Efter ett oplanerat avbrott kan meddelanden som „Recovering after a crash“, „Starting crash recovery“ och ett meddelande om att återhämtningen har slutförts visas. De beskriver inledningsvis en automatisk återhämtning efter ett systemkrasch vid serverstart. I samband med Binary Log eller tc.log De kan dessutom innehålla uppgifter om transaktionskoordinering. Dessa rader i sig utgör inte något bevis på skadade tabeller eller dataförlust.

Betyget ändras om en återställning utförs [FEL] om starten avbryts eller om meddelanden anger oläsbara eller skadade filer. Läs då igenom hela startsekvensen i kronologisk ordning och notera version, tidpunkt för avbrottet samt hela utdraget. En hänvisning till Binary Log eller tc.log innebär inte automatiskt ett reparationsuppdrag om det inte förekommer några följdfel.

Vid ett misstänkt dataproblem bör man inte radera filer eller vidta andra åtgärder som endast syftar till att tvinga fram en omstart. Klargör först syftet med åtgärden: att avgränsa felet, på ett kontrollerat sätt läsa ut tillgängliga data eller återställa en produktiv instans. Dokumentera därför loggutdraget, de befintliga säkerhetskopiorna och tillståndet för den berörda instansen separat.

Om en kontrollerad utläsning är möjlig ingår överföringen till en ren målinstans i planeringen, istället för att betrakta den berörda miljön som återställd. För att bättre förstå de transaktionsmekanismer som är inblandade är artikeln om MariaDB:s ångerloggar för administratörer. Vid upprepade krascher eller oklara filfel är det bättre att söka hjälp av en expert på dataåterställning än att fortsätta försöka starta datorn.

Skillnad mellan replikering och SQL-fel

I felloggen kan trådar, positioner, GTID:er eller reläloggar dyka upp i samband med replikeringsprocesser. Sådana uppgifter ger först och främst sammanhang för den berörda tidsperioden, men utgör ännu inte en fullständig feldiagnos. Spara raderna före och efter posten och kontrollera replikeringsstatusen separat. Det går inte att på ett tillförlitligt sätt avgöra utifrån en isolerad loggrad om en tråd har avslutats normalt eller om det föreligger ett avbrott.

Nyheter om förberedda transaktioner Efter ett systemkrasch krävs däremot särskild försiktighet. En heuristisk återställning fattar, beroende på vilken alternativ som väljs, ett beslut om commit eller rollback och bortser därvid från informationen från transaktionskoordineringen. Detta är inte ett steg för allmän felsökning i MySQL, utan ett specialfall vars konsekvenser för repliker och affärsdata måste utvärderas i förväg.

Felprotokollet registrerar serverhändelser, men är inte en fullständig logg över alla felaktiga SQL-kommandon. Binärloggar används främst för att registrera ändringar och för replikering; deras roll förklaras i artikeln om MariaDB:s binära loggar och deras prestandalogik. Slow Query Log är till hjälp vid långsamma sökningar, General Query Log används för omfattande övervakning av anslutningar och sökningar, och Audit Log har ett annat granskningssyfte.

För eventuella SQL-fel finns det en separat SQL_ERROR_LOG-plugin. Det kan även registrera fel som hanteras av en villkorshanterare och som därför tekniskt sett inte överförs till klienten. Plugin-modulen installeras inte automatiskt; från och med MariaDB 10.11.5 kan även varningar registreras om lämpliga inställningar har gjorts. Loggposterna kan innehålla användar- och värddatoruppgifter, databasnamn samt SQL-text. Planera därför restriktiva åtkomsträttigheter, lagring och rotation innan du aktiverar ytterligare loggning i en produktiv miljö.

Drift, eskalering och nästa steg

Vid misstänkta fall databasfel Börja med att ta ett sammanhängande loggutdrag med tidsstämplar, inte bara den sista raden. Notera även MariaDB-versionen inklusive paket-ID, startmekanism, observerat symptom och tidsmässig korrelation med driftsättningar, omstarter eller infrastrukturhändelser. Dessa uppgifter skiljer en möjlig orsak från dess konsekvenser och gör det möjligt att jämföra ledtrådar från applikationen, operativsystemet och databasen tillsammans.

Jämför därefter de alternativ som faktiskt har laddats in med den avsedda konfigurationen, istället för att ändra förmodade standardinställningar. Detta är särskilt viktigt eftersom paketering, MariaDB-version och kompatibilitetsnamn kan påverka inställningarna på olika sätt. Om det förekommer ett konfigurationsfel kan det hanteras på ett annat sätt än eventuella skador på lagringsutrymmet eller InnoDB.

Innan omstarter, återställningsförsök eller konfigurationsändringar är det en klok säkerhetsåtgärd att kontrollera tillgängliga säkerhetskopior och deras användbarhet. Dokumentera dessutom den planerade ändringen och en återgångsplan. Detta ersätter inte en orsaksanalys, men minskar risken för att en diagnostisk åtgärd döljer det ursprungliga tillståndet eller försvårar återställningen.

En enstaka åtkomstvägran eller avbruten anslutning kan inledningsvis observeras om den inte upprepas och applikationen samt tjänsten förblir stabila. Om sådana händelser blir allt vanligare bör du ta med klientvärden, applikationen, proxyservern och nätverket i utredningen. Upprepade startavbrott, oläsbara datafiler, misslyckad kraschåterställning eller tecken på förberedda transaktioner är däremot fall som kräver omedelbar eskalering med säkerhetskopierade originaldata.

Även en välfungerande logg behöver driftsregler. Övervaka Rotation av stockar och minnesanvändning, eftersom en högre loggnivå eller ytterligare SQL-felprotokoll snabbt kan göra filerna större. Begränsa åtkomsten till loggarna, eftersom de innehåller tekniska detaljer och eventuellt konfidentiellt innehåll från sökfrågor. Varaktiga ändringar är endast försvarbara efter att en dokumenterad orsak har fastställts, en återgångsplan har utarbetats och konsekvenserna för dataskydd och kapacitet har granskats.