Analyse og korrekt fortolkning af MariaDB-fejlloggen

Fejlloggens formål og begrænsninger

Das MariaDB-fejllog er serverprocessens driftslog. Den registrerer især start- og stop-operationer, kritiske serverhændelser samt oplysninger, der kan tyde på problemer med tabeller eller lagringsmotoren. Loggen er altid aktiv, men dens udgangskanal kan konfigureres på forskellige måder.

Her vises for eksempel mislykkede initialiseringer af plugins, ulæselige filer, afslag på adgang eller meddelelser om forbindelser. En linje med „Access denied“ beviser dog i første omgang kun, at en login-forsøg med de overførte data ikke blev accepteret. Om det skyldes adgangskoden, bruger-host-tilknytningen, godkendelsesmetoden eller den kaldende applikation, fremgår først af konteksten.

Fejlloggen er desuden ikke et fuldstændigt arkiv over alle SQL-fejl i et program. Til det formål findes der en separat SQL_ERROR_LOG-plugin; det kan skrive eventuelle SQL-fejl til en separat fil og tager også højde for fejl, som en Condition Handler behandler, inden de når frem til klienten. Pluginet er ikke installeret som standard. Dets poster kan indeholde bruger-, værts-, database- og SQL-oplysninger, hvorfor adgangsbeskyttelse og dataminimering bør være fastlagt, inden det tages i brug.

For Fejlfinding i MySQL Derfor er den kronologiske rækkefølge vigtigere end en enkelt afsluttende linje. Sørg først for at sikre et sammenhængende udsnit før og efter hændelsen. Hvis en konkret fejlmeddelelse efterfølges af flere efterfølgende poster og til sidst et afbryd, ligger den første relevante afvigelse ofte tættere på årsagen end den sidste synlige fejl. Også tidspunkt, observeret symptom og samtidige ændringer i applikationen eller systemet indgår i vurderingen.

Sikker fastlæggelse af lagringssteder

En manglende fil med filtypenavnet .err betyder ikke, at MariaDB ikke har logget noget. Fejlloggen kan skrives til en fil, til standardfejludgangen eller via Syslog til systemd-journalen; under Windows kommer hændelsesvisningen oveni. Hvilken variant der er aktiv, afhænger af serverindstillinger, pakkeopsætning og opstartsmekanismen for den konkrete installation.

Indstillingen log_error bestemmer destinationen ved filbaseret udskrivning. Et relativt filnavn fortolkes i forhold til datakataloget, mens en absolut sti er uafhængig heraf. Hvis der ikke udtrykkeligt er angivet et navn, beskriver dokumentationen en fil efter mønsteret »værtsnavn plus« .err i datakataloget. Man bør dog ikke udlede en fast sti heraf: Kontroller altid den faktisk gældende konfiguration.

De følgende kommandoer læser kun indstillinger fra indstillingsfiler. De er derfor et godt første spor til log_error, men afspejler ikke nødvendigvis den fulde konfiguration af den kørende proces. Yderligere startparametre samt systemd-unit- eller drop-in-overrides kan supplere eller ændre værdierne og skal kontrolleres separat.

Serverprocessen hedder i den aktuelle MariaDB-dokumentation mariadbd; mysqld kan, afhængigt af installationen, stadig forekomme som kompatibilitetsnavn. De to betegnelser bør derfor ikke sidestilles uden at tage højde for versions- og installationskonteksten. Kommandoerne ændrer hverken tjenesten eller dataene.

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

Ifølge dokumentationen er den anden kommando beregnet til MariaDB 10.11 og nyere; den tredje er relevant for installationer med den ældre programbetegnelse. Hvis du ikke finder en entydig filangivelse i optionsfilerne, skal du tjekke Journal eller Syslog samt parametrene for den tjeneste, der rent faktisk er startet, i stedet for at oprette en formodet logsti. Dette forhindrer, at diagnosticering og kørselskonfiguration kommer ud af trit med hinanden.

At fortolke linjeformat og kontekst korrekt

I filbaserede fejllogfiler i moderne MariaDB-versioner fra og med 10.1.5 følger en linje som regel mønsteret: tidsstempel, tråd-ID, niveau og meddelelse. Den Tidsstempel klassificerer hændelsen, tråd-ID’et gør det muligt at knytte den til andre poster fra samme serverforbindelse, og niveauet beskriver meddelelsens art. Først i sammenhæng med disse felter giver meddelelsen et pålideligt grundlag for diagnosticering.

I MariaDB op til og med version 10.1.4 er tidsformatet kortere, og visningen afviger fra det nyere skema. En parser eller en søgning, der forventer faste feltpositioner i det aktuelle format, kan derfor fortolke ældre logfiler forkert. Derudover kan eksterne SST-scripts i Galera-miljøer skrive linjer, hvor tråd-ID og niveau mangler. Sådanne specielle linjer er ikke nødvendigvis beskadigede logdata.

Det følgende uddrag er blot et skematisk eksempel på læseretningen i en mislykket opstartssekvens. Det bygger ikke på et konkret tilfælde og erstatter hverken den fulde opstartsudskrift eller kontrollen af de gældende indstillinger. Det afgørende er, at konfigurationsafvigelsen kommer før den afsluttende afbrydelsesmeddelelse.

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

Her er unknown variable Det første, der bør undersøges: Indstillingen kan være stavet forkert, ikke være tilgængelig i denne version eller være placeret i den forkerte konfigurationsfil. Aborting beskriver derimod slutpunktet for startsekvensen. Søg derfor baglæns frem til den første relevante meddelelse, og registrer derefter de efterfølgende linjer. På den måde skelner du mellem den sandsynlige årsag, serverens reaktion og de synlige konsekvenser af databasefejl helt adskilt fra hinanden.

Første optagelse uden risikable ændringer

Inden du fortolker en meddelelse eller ændrer indstillingerne, skal du sikkerhedskopiere Driftskontekst: den fulde MariaDB-version, herunder eventuelle pakke- eller distributionstilføjelser, operativsystem, opstartsmekanisme, tidspunkt og synligt symptom. En genstart, en mislykket login eller et afbrudt replikationsforløb er forskellige hændelser. Uden disse oplysninger kan den samme loglinje ikke vurderes pålideligt.

Kopier desuden ikke et enkelt resultat, men et sammenhængende uddrag før og efter den første bemærkelsesværdige hændelse. Notér, hvornår problemet opstod for brugere eller applikationer, og om der samtidig fandt ændringer i konfiguration, implementering eller netværk sted. På den måde kan udløsende faktorer, følgefejl og den normale start- eller stopsekvens adskilles tidsmæssigt fra hinanden.

Følgende kommandoer læser udelukkende oplysninger fra indstillingsfiler og ændrer hverken tjenester eller data. De er især nyttige til at finde en indstilling, der er angivet der log_error kan findes. De viser dog ikke automatisk alle de værdier, som tjenesten rent faktisk blev startet med: Yderligere startparametre, systemd-unit-filer og drop-ins skal du kontrollere separat.

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

Fra og med MariaDB 10.11 dokumenterer MariaDB my_print_defaults --mariadbd til denne forespørgsel. Navnet mariadbd betegner den aktuelle serverproces; mysqld bevares i mange installationer som en ældre betegnelse eller et kompatibilitetsnavn. Du bør derfor ikke betragte de to navne som tegn på, at der er tale om den samme konkrete serverversion eller det samme tjenestenavn.

Hvis loggen findes i systemd-journalen, skal du indsnævre tidsvinduet ved hjælp af det unit-navn, der er kontrolleret på systemet. Kontroller om nødvendigt også unit-filen og eventuelle drop-ins, så yderligere startparametre ikke overses. Tilføj derefter uddraget fra applikationsloggen for samme tidsperiode, hvis symptomet viser sig i en applikation.

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

Klassificering af niveauer og startfejl

Mærkninger giver struktur til MariaDB-fejlloggen, men erstatter ikke en årsagsanalyse. En Alvorlighed beskriver placeringen af en linje, ikke nødvendigvis skadens omfang eller alvoren. Især ved et opstartsproblem er rækkefølgen afgørende: En tidligere konkret fejlmeddelelse forklarer ofte en senere Aborting, mens bemærkninger før dette også kan omhandle almindelig initialisering.

Hvis MariaDB ikke starter, skal du først indsnævre den seneste opstartssekvens i loggen og derefter læse den baglæns. Se især efter unknown variable, manglende eller ulæselige filer, problemer med brugerrettigheder og fejl ved initialisering af plugins. MariaDB henviser til fejlloggen som den primære kilde ved mislykkede opstarter; ved manuel opstart kan årsagen desuden vises på konsollen.

En Konfigurationsfejl Dette skyldes oftest en ukendt indstilling, en forkert skrivemåde eller en uoverensstemmende værdi i en indlæst fil. Kontroller derfor først de aktive indstillinger og versionstilknytningen, i stedet for at røre ved datamængderne. En fejl ved åbning af en datafil eller en InnoDB-meddelelse kan derimod vedrøre tilladelser, stier, lagerplads eller datatilstand og kræver en betydeligt mere forsigtig vurdering.

Du bør ikke ændre flere parametre på én gang for at tvinge systemet til at starte. Gem et udsnit af logfilen, og noter, hvilken ændring der gik forud for fejlen. Først når den første relevante fejlmeddelelse er knyttet til en kontrolleret indstilling eller ressource, kan man planlægge en målrettet og sporbar løsning.

Diagnostisk vurdering af hyppige symptomer

Tilbagevendende formuleringer forkorter søgningen, men giver sjældent en diagnose i sig selv. Tilknyt hver meddelelse til et tidsvindue, den berørte host eller tråd og det observerede symptom. Tabellen angiver bevidst kun de næste diagnostiske trin: Den forhindrer, at man forhastet udleder en årsag i databaseserveren ud fra en henvisning til forbindelser, filer eller replikering.

Med Adgang nægtet Det er først og fremmest afgørende, for hvilken bruger og klient-host loginforsøget blev afvist. Kontroller den anvendte applikationskonfiguration og tidspunktet, ikke kun adgangskoden isoleret set. Meddelelsen kan skyldes forkerte adgangsoplysninger, en afvigende værtshenvisning eller en uoverensstemmende autentificering; den er ikke tegn på en beskadiget database.

En Afbrudt forbindelse kan skyldes en applikationstimeout, en afbrudt netværksforbindelse, en proxy eller fejl i pakkekommunikationen. Sammenlign klient-host og tråd-ID med applikationsloggen. Brug globale værdier i stedet for sessionsrelaterede værdier for tællere; ellers kan en nyoprettet session vise vildledende lave værdier.

SHOW GLOBAL STATUS LIKE 'Aborted%';

Forespørgslen viser tællere, men ingen fuldstændig årsag og ingen tilknytning til en bestemt klient. Vurder derfor ændringer over en passende periode sammen med uddrag fra logfilerne. Ved replikations- eller GTID-henvisninger skal du desuden dokumentere de efterfølgende linjer og kontrollere replikationsstatus ved hjælp af de dertil beregnede statusoplysninger; fejlloglinjen alene er ikke tilstrækkelig til en fuldstændig replikationsdiagnose.

Vurder InnoDB-gendannelse uden risiko for tab af data

Efter et uplanlagt nedbrud kan der vises meddelelser som „Recovering after a crash“, „Starting crash recovery“ og en meddelelse om, at genoprettelsen er gennemført. De beskriver i første omgang en automatisk genoprettelse efter nedbrud ved serverstart. I forbindelse med Binary Log eller tc.log De kan desuden indeholde oplysninger om transaktionskoordinering. Disse linjer alene er ikke tegn på beskadigede tabeller eller datatab.

Vurderingen ændrer sig, hvis der efter gendannelsen [FEJL] hvis opstarten afbrydes, eller hvis meddelelserne angiver ulæselige eller beskadigede filer. Læs derefter hele opstartssekvensen i kronologisk rækkefølge, og noter versionen, tidspunktet for fejlen samt det fulde uddrag. En henvisning til Binary Log eller tc.log udgør ikke i sig selv en reparationsopgave, hvis der ikke er nogen efterfølgende fejl.

Ved mistanke om et dataproblem bør der ikke foretages filsletninger eller andre indgreb, der udelukkende har til formål at tvinge systemet til at starte op. Afklar først formålet med foranstaltningen: at indkredse fejlen, kontrollere udlæsning af tilgængelige data eller gendanne en produktiv instans. Notér derfor loguddraget, de eksisterende sikkerhedskopier og den berørte instans’ tilstand hver for sig.

Hvis en kontrolleret udlæsning er mulig, skal overførslen til en fejlfri målinstans indgå i planlægningen, i stedet for at betragte det berørte miljø som rettet. For at forstå de involverede transaktionsmekanismer er artiklen om MariaDB-undo-logfiler for administratorer. Ved gentagne nedbrud eller uklare filfejl er det mere fornuftigt at søge hjælp fra en ekspert i datagendannelse end at fortsætte med at forsøge at starte systemet op.

Adskill replikering og SQL-fejl

I fejlloggen kan der ved replikeringsprocesser forekomme tråde, positioner, GTID’er eller relélogfiler. Sådanne oplysninger giver i første omgang kontekst for det pågældende tidsrum, men endnu ikke en fuldstændig fejldiagnose. Skriv linjerne før og efter posten ned, og kontroller replikationsstatus separat. Det er ikke muligt pålideligt at afgøre ud fra en isoleret loglinje, om en tråd er afsluttet normalt, eller om der er tale om en afbrydelse.

Meddelelser om forberedte transaktioner Efter et nedbrud kræver det derimod særlig forsigtighed. En heuristisk gendannelse træffer, afhængigt af den valgte indstilling, en beslutning om commit eller rollback og ignorerer derved oplysninger fra transaktionskoordineringen. Dette er ikke et trin i almindelig MySQL-fejlfinding, men et særligt tilfælde, hvis konsekvenser for replikater og forretningsdata skal vurderes på forhånd.

Fejlloggen registrerer serverhændelser, men er ikke en fuldstændig log over alle fejlbehæftede SQL-sætninger. Binære logfiler bruges primært til registrering af ændringer og replikering; deres rolle forklares i artiklen om MariaDB-binærlogfiler og deres præstationslogik. Slow Query Log hjælper ved langsomme forespørgsler, General Query Log ved omfattende overvågning af forbindelser og forespørgsler, og et Audit Log tjener et andet kontrolformål.

I tilfælde af SQL-fejl findes der en separat SQL_ERROR_LOG-plugin. Det kan også registrere fejl, som en Condition Handler behandler, og som derfor teknisk set ikke overføres til klienten. Pluginet installeres ikke automatisk; fra MariaDB 10.11.5 kan der også registreres advarsler, hvis indstillingerne er korrekte. Logposterne kan indeholde bruger- og værtsdata, databasenavne samt SQL-tekst. Planlæg derfor restriktive adgangsrettigheder, opbevaring og rotation, inden du aktiverer yderligere logning i et produktionsmiljø.

Drift, eskalering og næste skridt

Vær opmærksom på mistænkelige databasefejl Først et sammenhængende uddrag af logfilen med tidsstempler, ikke kun den sidste linje. Notér i den forbindelse MariaDB-versionen samt pakkekode, opstartsmekanisme, det observerede symptom og den tidsmæssige sammenhæng med implementeringer, genstarter eller infrastrukturhændelser. Disse data adskiller en mulig årsag fra dens konsekvenser og gør det muligt at sammenligne oplysninger fra applikationen, operativsystemet og databasen.

Sammenlign derefter de indlæste indstillinger med den ønskede konfiguration, i stedet for at ændre formodede standardindstillinger. Dette er særligt vigtigt, da pakker, MariaDB-version og kompatibilitetsnavne kan påvirke indstillingerne på forskellig vis. Hvis der foreligger en konfigurationsfejl, kan den håndteres anderledes end en eventuel skade på lageret eller InnoDB.

Inden genstart, genoprettelsesforsøg eller konfigurationsændringer er det en fornuftig sikkerhedsforanstaltning at kontrollere, om der findes sikkerhedskopier, og om de kan bruges. Dokumenter desuden den planlagte ændring og en plan for tilbagevenden til den oprindelige tilstand. Dette erstatter ikke en årsagsanalyse, men mindsker risikoen for, at en diagnostisk foranstaltning skjuler den oprindelige tilstand eller vanskeliggør gendannelsen.

En enkelt afvisning af adgang eller en afbrudt forbindelse kan i første omgang blot observeres, så længe den ikke gentager sig, og applikationen samt tjenesten forbliver stabile. Hvis sådanne hændelser forekommer hyppigt, skal du inddrage klient-host, applikation, proxy og netværk. Gentagne afbrudte opstarter, ulæselige datafiler, mislykkede crash-genopretninger eller tegn på forberedte transaktioner er derimod tilfælde, der kræver en hurtig eskalering med sikkerhedskopierede originaldata.

Selv et velfungerende log har brug for driftsregler. Overvåg Rotation af træstammer og lagerforbrug, da en højere logniveauindstilling eller yderligere SQL-fejllogfiler hurtigt kan øge filstørrelsen. Begræns adgangen til logfiler, da de indeholder tekniske detaljer og eventuelt fortrolige oplysninger om forespørgsler. Varige ændringer kan først anses for forsvarlige, når der foreligger en dokumenteret årsag, en genopretningsplan og en vurdering af konsekvenserne for databeskyttelse og kapacitet.