Het foutenlogboek van MariaDB analyseren en correct interpreteren

Doel en beperkingen van het foutenlogboek

De MariaDB-foutlogboek Dit is het logboek van het serverproces. Hierin worden met name start- en stopbewerkingen, kritieke servergebeurtenissen en opmerkingen vastgelegd die kunnen wijzen op problemen met tabellen of de opslagengine. Het logboek is altijd actief, maar de uitvoerkanalen ervan kunnen op verschillende manieren worden geconfigureerd.

Daarin verschijnen bijvoorbeeld mislukte initialisaties van plug-ins, onleesbare bestanden, toegangsweigeringen of meldingen over verbindingen. Een regel met „Access denied“ bewijst echter in eerste instantie alleen dat een aanmelding met de verzonden gegevens niet is geaccepteerd. Of dit nu te wijten is aan het wachtwoord, de koppeling tussen gebruiker en host, de authenticatiemethode of de aanroepende toepassing, blijkt pas uit de context.

Het foutenlogboek is bovendien geen volledig archief van alle SQL-fouten van een toepassing. Daarvoor is er het aparte SQL_ERROR_LOG-plug-in; het kan SQL-fouten die optreden naar een apart bestand schrijven en houdt daarbij ook rekening met fouten die door een condition handler worden verwerkt voordat ze de client bereiken. De plug-in is niet standaard geïnstalleerd. De vermeldingen kunnen gebruikers-, host-, database- en SQL-informatie bevatten, waardoor toegangsbeveiliging en gegevensminimalisatie vóór het gebruik moeten worden vastgelegd.

Voor Problemen met MySQL oplossen Daarom is de chronologische volgorde belangrijker dan een op zichzelf staande afsluitende regel. Zorg eerst voor een samenhangend fragment vóór en na de gebeurtenis. Als een concrete foutmelding wordt gevolgd door meerdere opeenvolgende vermeldingen en uiteindelijk een afbreking, ligt de eerste relevante afwijking vaak dichter bij de oorzaak dan de laatste zichtbare fout. Ook het tijdstip, het waargenomen symptoom en gelijktijdige wijzigingen aan de toepassing of het systeem maken deel uit van de beoordeling.

Opslaglocaties betrouwbaar vaststellen

Een ontbrekend bestand met de extensie .err betekent niet dat MariaDB niets heeft gelogd. Het foutenlogboek kan naar een bestand, naar de standaardfoutuitvoer of via Syslog naar het systemd-logboek worden geschreven; onder Windows komt daar het gebeurtenissenlogboek bij. Welke variant actief is, hangt af van de serveropties, de pakketconfiguratie en het opstartmechanisme van de specifieke installatie.

De optie log_error bepaalt bij bestandsgebaseerde uitvoer de bestemming. Een relatieve bestandsnaam wordt geïnterpreteerd ten opzichte van de gegevensmap; een absoluut pad blijft daarvan onafhankelijk. Zonder expliciet opgegeven naam beschrijft de documentatie een bestand volgens het patroon hostnaam plus .err in de gegevensmap. Hieruit mag je echter geen vast pad afleiden: controleer altijd de daadwerkelijk geldende configuratie.

De volgende commando’s lezen alleen opties uit optiebestanden. Ze vormen daarom een goed eerste aanknopingspunt voor log_error, maar geven niet noodzakelijkerwijs de volledige configuratie van het lopende proces weer. Extra startparameters en systemd-unit- of drop-in-overrides kunnen waarden aanvullen of wijzigen en moeten afzonderlijk worden gecontroleerd.

In de huidige MariaDB-documentatie heet het serverproces mariadbd; mysqld kan, afhankelijk van de installatie, nog steeds als compatibiliteitsnaam voorkomen. Beide benamingen mogen daarom niet zonder de context van de versie en de installatie met elkaar worden gelijkgesteld. De commando’s brengen geen wijzigingen aan in de dienst of de gegevens.

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

Volgens de documentatie is het tweede commando bedoeld voor MariaDB 10.11 en hoger; het derde commando is relevant voor installaties met de oudere programmanaam. Als je in de optiebestanden geen duidelijke bestandsvermelding vindt, controleer je dan het logboek of syslog en de parameters van de daadwerkelijk gestarte dienst, in plaats van een verondersteld logpad aan te maken. Dit voorkomt dat de diagnose en de configuratie tijdens de uitvoering uit elkaar lopen.

De regelindeling en de context correct interpreteren

In de op bestanden gebaseerde foutenlogboeken van moderne MariaDB-versies vanaf 10.1.5 volgt een regel in principe het patroon: tijdstempel, thread-ID, niveau en bericht. De Tijdstempel geeft de gebeurtenis een classificatie, de thread-ID kan deze koppelen aan andere vermeldingen van dezelfde serververbinding, en het niveau beschrijft het soort melding. Pas in combinatie met deze velden biedt het bericht een betrouwbare basis voor de diagnose.

In MariaDB tot en met versie 10.1.4 is de tijdnotatie korter en wijkt de weergave af van het nieuwere schema. Een parser of zoekopdracht die vaste veldposities van het huidige formaat verwacht, kan oudere logbestanden daarom verkeerd ontleden. Bovendien kunnen externe SST-scripts in Galera-omgevingen regels schrijven waarin de thread-ID en het niveau ontbreken. Dergelijke speciale regels zijn niet automatisch beschadigde loggegevens.

Het volgende fragment is slechts een schematisch voorbeeld van de leesvolgorde bij een mislukte opstartprocedure. Het is niet gebaseerd op een concreet geval en vervangt noch de volledige opstartuitvoer, noch de controle van de geldige opties. Het is van cruciaal belang dat de afwijking in de configuratie vóór de afsluitende afbrekingsmelding staat.

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

Hier is unknown variable De eerste aanwijzing die nader onderzocht moet worden: de optie kan verkeerd zijn geschreven, niet beschikbaar zijn voor deze versie of in het verkeerde configuratiebestand staan. Aborting beschrijft daarentegen het eindpunt van de startsequentie. Zoek daarom achteruit tot aan het eerste relevante bericht en noteer vervolgens de volgende regels. Zo maak je onderscheid tussen de waarschijnlijke oorzaak, de reactie van de server en de zichtbare gevolgen van de databasefouten duidelijk van elkaar gescheiden.

Eerste opname zonder risicovolle wijzigingen

Voordat je een melding interpreteert of instellingen wijzigt, maak dan een back-up van de Bedrijfscontext: de volledige MariaDB-versie, inclusief pakket- of distributietoevoeging, besturingssysteem, opstartmechanisme, tijdstip en zichtbaar symptoom. Een herstart, een mislukte aanmelding of een onderbreking van de replicatie zijn verschillende gebeurtenissen. Zonder deze gegevens kan dezelfde logregel niet op betrouwbare wijze worden beoordeeld.

Kopieer bovendien niet één enkel trefpunt, maar een samenhangend fragment vóór en na de eerste opvallende gebeurtenis. Noteer wanneer het probleem voor gebruikers of applicaties begon en of er tegelijkertijd wijzigingen in de configuratie, de implementatie of het netwerk plaatsvonden. Zo kunnen triggers, vervolgfouten en de normale start- of stopvolgorde in de tijd van elkaar worden gescheiden.

De volgende commando’s lezen uitsluitend gegevens uit optiebestanden en brengen geen wijzigingen aan in de dienst of de gegevens. Ze zijn vooral nuttig om een daar ingestelde optie log_error te vinden. Ze tonen echter niet automatisch alle waarden waarmee de dienst daadwerkelijk is gestart: extra opstartparameters, systemd-unit-bestanden en drop-ins moet je apart controleren.

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

Vanaf MariaDB 10.11 documenteert MariaDB my_print_defaults --mariadbd voor deze zoekopdracht. De naam mariadbd verwijst naar het huidige serverproces; mysqld blijft in veel installaties behouden als oudere benaming of compatibiliteitsverwijzing. Beschouw beide namen daarom niet als bewijs voor dezelfde specifieke serverversie of dezelfde servicenaam.

Als het logboek in het systemd-journaal staat, beperk dan het tijdsbestek aan de hand van de unitnaam die op het systeem is gecontroleerd. Controleer indien nodig ook het unit-bestand en de aanwezige drop-ins, zodat er geen extra opstartparameters over het hoofd worden gezien. Voeg vervolgens het fragment uit het applicatielogboek van dezelfde periode toe, indien het symptoom zich via een applicatie manifesteert.

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

Niveaus en startfouten indelen

Markeringen geven structuur aan het MariaDB-foutenlogboek, maar zijn geen vervanging voor een oorzaakanalyse. Een Ernst geeft de indeling van een regel weer, niet automatisch de ernst of de urgentie. Juist bij een opstartprobleem is de volgorde bepalend: een eerdere concrete foutmelding verklaart vaak een latere Aborting, terwijl opmerkingen daarvoor ook de normale initialisatie kunnen beschrijven.

Als MariaDB niet opstart, zoek dan eerst de laatste opstartreeks in het logboek en lees deze vervolgens achteruit. Zoek met name naar unknown variable, ontbrekende of onleesbare bestanden, machtigingsproblemen en fouten bij het initialiseren van plug-ins. MariaDB verwijst bij mislukte opstartpogingen naar het foutenlogboek als primaire bron; bij handmatig opstarten kan de oorzaak bovendien op de console worden weergegeven.

A Configuratiefout Dit heeft meestal te maken met een onbekende optie, een verkeerde schrijfwijze of een onjuiste waarde in een ingelezen bestand. Controleer in dat geval eerst de actieve opties en de versie-indeling, in plaats van de gegevensbestanden aan te raken. Een fout bij het openen van een gegevensbestand of een InnoDB-melding kan daarentegen betrekking hebben op machtigingen, paden, opslagruimte of de toestand van de gegevens en vereist een aanzienlijk zorgvuldiger beoordeling.

Wijzig niet meerdere parameters tegelijk om het systeem te dwingen op te starten. Sla het logfragment op en noteer welke wijziging aan de fout voorafging. Pas wanneer het eerste relevante bericht aan een gecontroleerde instelling of bron is toegewezen, kan een gerichte, traceerbare correctie worden gepland.

Veelvoorkomende meldingen diagnostisch beoordelen

Terugkerende formuleringen verkorten het zoekproces, maar leveren op zichzelf zelden een diagnose op. Koppel elke melding aan een tijdvenster, de betreffende host of thread en het waargenomen symptoom. De tabel vermeldt bewust alleen diagnostische vervolgstappen: zo wordt voorkomen dat uit een verwijzing naar verbindingen, bestanden of replicatie overhaast een oorzaak in de databaseserver wordt afgeleid.

Op Toegang geweigerd Het is in de eerste plaats van belang voor welke gebruiker en client-host de aanmelding is geweigerd. Controleer de gebruikte applicatieconfiguratie en het tijdstip, en kijk niet alleen naar het wachtwoord op zich. De melding kan het gevolg zijn van onjuiste inloggegevens, een afwijkende hostverwijzing of een onjuiste authenticatie; het wijst niet op een beschadigde database.

A Verbinding afgebroken kan te maken hebben met een time-out van de toepassing, een onderbroken netwerkverbinding, een proxy of foutieve pakketcommunicatie. Vergelijk de client-host en de thread-ID met het applicatielogboek. Gebruik voor tellers globale waarden in plaats van sessiegebonden waarden; anders kan een nieuw opgestarte sessie misleidend lage waarden weergeven.

SHOW GLOBAL STATUS LIKE 'Aborted%';

De query toont tellers, maar geen volledige oorzaak en geen toewijzing aan een specifieke client. Beoordeel veranderingen daarom over een passende periode in combinatie met logfragmenten. Bij replicatie- of GTID-meldingen moet u bovendien de volgende regels documenteren en de replicatiestatus controleren aan de hand van de daarvoor bestemde statusinformatie; de regel in het foutenlogboek alleen is niet voldoende voor een volledige replicatiediagnose.

InnoDB-herstel beoordelen zonder risico voor de gegevens

Na een onvoorziene onderbreking kunnen meldingen verschijnen zoals „Recovering after a crash“, „Starting crash recovery“ en een bericht dat het proces succesvol is afgerond. Deze beschrijven in eerste instantie een automatisch herstel na een crash bij het opstarten van de server. In verband met het binaire logboek of tc.log Ze kunnen bovendien informatie bevatten over de coördinatie van transacties. Deze regels op zich vormen geen bewijs van beschadigde tabellen of gegevensverlies.

De beoordeling verandert als er na het herstel een [FOUT] volgt, de start wordt afgebroken of er meldingen verschijnen over onleesbare of beschadigde bestanden. Lees vervolgens de volledige startsequentie in chronologische volgorde door en noteer de versie, het tijdstip van de storing en het volledige fragment. Een verwijzing naar Binary Log of tc.log is, zonder vervolgfouten, nog geen reparatieopdracht.

Bij een vermoedelijk gegevensprobleem mogen er geen bestanden worden verwijderd of andere ingrepen worden gedaan die uitsluitend bedoeld zijn om het systeem opnieuw op te starten. Bepaal eerst het doel van de maatregel: de fout inperken, beschikbare gegevens op gecontroleerde wijze uitlezen of een productieve instantie herstellen. Leg hiervoor het logfragment, de beschikbare back-ups en de status van de betreffende instantie afzonderlijk vast.

Als een gecontroleerde uitlezing mogelijk is, hoort de overgang naar een schone doelinstantie deel uit te maken van de planning, in plaats van de betreffende omgeving als hersteld te beschouwen. Om inzicht te krijgen in de betrokken transactiemechanismen is het artikel over MariaDB-undo-logs voor beheerders. Bij herhaaldelijke systeemcrashes of onduidelijke bestandsfouten is deskundige hulp bij het herstel zinvoller dan verdere pogingen om het systeem op te starten.

Replicatie en SQL-fouten scheiden

In het foutenlogboek kunnen bij replicatieprocessen threads, posities, GTID’s of relaislogboeken verschijnen. Dergelijke gegevens bieden in eerste instantie context voor de betreffende periode, maar nog geen volledige foutdiagnose. Sla de regels vóór en na het bericht op en controleer de replicatiestatus afzonderlijk. Of een thread op normale wijze is beëindigd of dat er sprake is van een onderbreking, kan niet op betrouwbare wijze worden afgeleid uit een op zichzelf staande logregel.

Berichten over voorbereide transacties Na een crash is daarentegen bijzondere voorzichtigheid geboden. Een heuristische herstelprocedure neemt, afhankelijk van de gekozen optie, een beslissing over commit of rollback en negeert daarbij informatie van de transactiecoördinatie. Dit is geen stap voor algemene MySQL-probleemoplossing, maar een speciaal geval waarvan de gevolgen voor replica's en bedrijfsgegevens vooraf moeten worden beoordeeld.

Het foutenlogboek registreert servergebeurtenissen, maar is geen volledig logboek van alle foutieve SQL-opdrachten. Binaire logboeken dienen vooral voor het vastleggen van wijzigingen en replicatie; hun rol wordt toegelicht in het artikel over MariaDB-binaire logbestanden en hun prestatielogica. Het Slow Query Log helpt bij trage query’s, het General Query Log bij uitgebreide monitoring van verbindingen en query’s, en een Audit Log dient een ander controledoel.

Voor SQL-fouten die zich voordoen, is er het aparte SQL_ERROR_LOG-plug-in. Het kan ook fouten registreren die door een condition handler worden verwerkt en die daarom technisch gezien niet naar de client worden verzonden. De plug-in wordt niet automatisch geïnstalleerd; vanaf MariaDB 10.11.5 kunnen, mits de juiste instellingen zijn gekozen, ook waarschuwingen worden geregistreerd. De logboekvermeldingen kunnen gebruikers- en hostgegevens, databasnamen en SQL-tekst bevatten. Zorg daarom voor restrictieve toegangsrechten, bewaartermijnen en rotatie voordat je extra logboekregistratie in een productieomgeving activeert.

Bedrijf, escalatie en volgende stappen

Zorg ervoor dat bij opvallende databasefouten Eerst een samenhangend fragment uit het logboek met tijdstempels, niet alleen de laatste regel. Noteer daarbij de MariaDB-versie inclusief pakket-ID, het opstartmechanisme, het waargenomen symptoom en de temporele correlatie met deployments, herstarts of infrastructuurgebeurtenissen. Deze gegevens maken het mogelijk om een mogelijke oorzaak te onderscheiden van de gevolgen ervan en om aanwijzingen uit de applicatie, het besturingssysteem en de database gezamenlijk te vergelijken.

Vergelijk vervolgens de daadwerkelijk ingelezen opties met de beoogde configuratie, in plaats van veronderstelde standaardinstellingen te wijzigen. Dit is vooral belangrijk omdat de pakketversie, de MariaDB-versie en compatibiliteitsnamen de opties op verschillende manieren kunnen beïnvloeden. Als er een configuratiefout is, kan deze anders worden aangepakt dan mogelijke schade aan de opslag of aan InnoDB.

Voordat u het systeem opnieuw opstart, herstelpogingen onderneemt of configuratiewijzigingen doorvoert, is het een verstandige veiligheidsmaatregel om de beschikbare back-ups en hun bruikbaarheid te controleren. Documenteer bovendien de geplande wijziging en een terugvalplan. Dit is geen vervanging voor een oorzaakanalyse, maar vermindert wel het risico dat een diagnostische maatregel de oorspronkelijke toestand verhult of het herstel bemoeilijkt.

Een eenmalige weigering van toegang of een verbroken verbinding kan in eerste instantie worden genegeerd, mits deze zich niet herhaalt en de applicatie en de dienst stabiel blijven. Als dergelijke voorvallen zich vaker voordoen, moet je de client-host, de applicatie, de proxy en het netwerk in het onderzoek betrekken. Herhaaldelijke afgebroken opstartpogingen, onleesbare gegevensbestanden, mislukte crash-recovery of aanwijzingen voor voorbereide transacties zijn daarentegen gevallen die een onmiddellijke escalatie vereisen, waarbij de originele gegevens moeten worden veiliggesteld.

Zelfs een goed functionerend logboek heeft gebruiksregels nodig. Houd toezicht op Logboekrotatie en geheugengebruik, want een hogere verbositeit of extra SQL-foutlogboeken kunnen bestanden snel doen groeien. Beperk de toegang tot logboeken, omdat deze technische details en mogelijk vertrouwelijke query-inhoud bevatten. Permanente wijzigingen zijn pas verantwoord na vaststelling van een gedocumenteerde oorzaak, het opstellen van een noodplan en een beoordeling van de gevolgen voor de gegevensbescherming en de capaciteit.