Analizzare e interpretare correttamente il log degli errori di MariaDB

Funzione e limiti del registro degli errori

Il sito Registro degli errori di MariaDB È il log di funzionamento del processo del server. Registra in particolare le operazioni di avvio e arresto, gli eventi critici del server e le segnalazioni che potrebbero indicare, ad esempio, problemi con le tabelle o con il motore di archiviazione. Il log è sempre attivo, ma il suo canale di output può essere configurato in modi diversi.

In esso compaiono, ad esempio, inizializzazioni non riuscite di plugin, file illeggibili, accessi negati o messaggi relativi alle connessioni. Una riga con la dicitura „Access denied“, tuttavia, dimostra inizialmente solo che un tentativo di accesso con i dati trasmessi non è stato accettato. Se la causa sia da ricercarsi nella password, nell’associazione utente-host, nel metodo di autenticazione o nell’applicazione chiamante, si può dedurre solo dal contesto.

Inoltre, il registro degli errori non è un archivio completo di tutti gli errori SQL di un’applicazione. A tale scopo esiste il file separato Plugin SQL_ERROR_LOG; può scrivere gli errori SQL che si verificano in un file dedicato, tenendo conto anche degli errori gestiti da un Condition Handler prima che raggiungano il client. Il plugin non è installato di default. Le sue voci possono contenere informazioni relative a utenti, host, database e SQL; pertanto, prima dell’utilizzo è necessario definire le misure di protezione dell’accesso e di minimizzazione dei dati.

Per Risoluzione dei problemi di MySQL Pertanto, la sequenza temporale è più importante di una singola riga finale. Assicurati innanzitutto di individuare un frammento coerente prima e dopo l’evento. Se a un messaggio di errore specifico seguono diverse voci successive e infine un’interruzione, la prima anomalia rilevante è spesso più vicina alla causa rispetto all’ultimo errore visibile. Anche il momento, il sintomo osservato e le modifiche simultanee all’applicazione o al sistema fanno parte della valutazione.

Individuare con certezza le posizioni di archiviazione

Un file mancante con l'estensione .err non significa che MariaDB non abbia registrato nulla. Il log degli errori può essere scritto in un file, sull'output di errore predefinito o tramite Syslog nel journal di systemd; su Windows si aggiunge anche il Registro eventi. Quale variante sia attiva dipende dalle opzioni del server, dal pacchetto e dal meccanismo di avvio della specifica installazione.

L'opzione log_error Determina la destinazione in caso di output basato su file. Un nome di file relativo viene interpretato rispetto alla directory dei dati, mentre un percorso assoluto rimane indipendente da essa. Se il nome non viene specificato esplicitamente, la documentazione descrive un file secondo lo schema “nome host più” .err nella directory dei dati. Tuttavia, non si dovrebbe dedurne un percorso fisso: verifica sempre la configurazione effettivamente in uso.

I comandi seguenti leggono solo le opzioni dai file di opzioni. Rappresentano quindi un buon punto di partenza per log_error, ma non riflettono necessariamente la configurazione completa del processo in esecuzione. Parametri di avvio aggiuntivi, nonché le sostituzioni delle unità systemd o le sostituzioni "drop-in", possono integrare o modificare i valori e devono essere verificati separatamente.

Nella documentazione attuale di MariaDB, il processo del server si chiama mariadbd; mysqld A seconda dell'installazione, può comunque comparire come nome di compatibilità. Non bisogna quindi equiparare le due denominazioni senza considerare il contesto della versione e dell'installazione. I comandi non modificano né il servizio né i dati.

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

Secondo la documentazione, il secondo comando è previsto a partire da MariaDB 10.11; il terzo è rilevante per le installazioni con la denominazione precedente del programma. Se nei file delle opzioni non trovi alcuna indicazione significativa sul file, controlla il Journal o il Syslog nonché i parametri del servizio effettivamente avviato, invece di creare un percorso di log ipotetico. Ciò impedisce che la diagnostica e la configurazione di runtime divergano.

Leggere correttamente il formato delle righe e il contesto

Nei log di errore basati su file delle versioni moderne di MariaDB a partire dalla 10.1.5, ogni riga segue generalmente lo schema: timestamp, ID thread, livello e messaggio. Il Timestamp classifica l'evento; l'ID del thread consente di collegarlo ad altre voci relative alla stessa connessione al server, mentre il livello descrive il tipo di messaggio. Solo in combinazione con questi campi il messaggio fornisce un approccio affidabile per la diagnosi.

In MariaDB fino alla versione 10.1.4 inclusa, il formato dell'ora è più breve e la rappresentazione differisce dallo schema più recente. Un parser o una ricerca che si aspetti posizioni fisse dei campi nel formato attuale potrebbe quindi analizzare in modo errato i log più vecchi. Inoltre, negli ambienti Galera, gli script SST esterni possono scrivere righe prive di ID thread e livello. Tali righe speciali non costituiscono automaticamente dati di log danneggiati.

Il seguente frammento è solo un esempio schematico della sequenza di lettura di una sequenza di avvio fallita. Non si basa su un caso reale e non sostituisce né l'output completo dell'avvio né la verifica delle opzioni effettive. È fondamentale che la discrepanza di configurazione preceda il messaggio finale di interruzione.

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

Ecco unknown variable Il primo elemento da verificare: l'opzione potrebbe essere scritta in modo errato, non essere disponibile in questa versione oppure trovarsi nel file di configurazione sbagliato. Aborting descrive invece il punto finale della sequenza di avvio. Cerca quindi a ritroso fino al primo messaggio rilevante e registra poi le righe successive. In questo modo puoi distinguere la causa probabile, la reazione del server e gli effetti visibili della errori del database ben separati l'uno dall'altro.

Prima registrazione senza modifiche rischiose

Prima di interpretare un messaggio o modificare le impostazioni, esegui il backup del Contesto operativo: la versione completa di MariaDB, compresi eventuali pacchetti o componenti aggiuntivi della distribuzione, il sistema operativo, il meccanismo di avvio, l'ora e il sintomo visibile. Un riavvio, un accesso non riuscito o l'interruzione della replica sono eventi distinti. Senza queste informazioni, non è possibile valutare in modo attendibile la stessa riga di log.

Inoltre, non copiare un singolo risultato, ma un frammento coerente che comprenda sia la parte precedente che quella successiva al primo evento rilevante. Annota quando il problema è iniziato per gli utenti o le applicazioni e se, parallelamente, sono state apportate modifiche alla configurazione, alla distribuzione o alla rete. In questo modo è possibile distinguere temporalmente i fattori scatenanti, gli errori conseguenti e la normale sequenza di avvio o arresto.

I comandi seguenti leggono esclusivamente le impostazioni dai file di opzioni e non modificano né il servizio né i dati. Sono particolarmente utili per configurare un’opzione impostata in tali file log_error da trovare. Tuttavia, non mostrano automaticamente tutti i valori con cui il servizio è stato effettivamente avviato: i parametri di avvio aggiuntivi, i file delle unità systemd e i drop-in vanno controllati separatamente.

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

A partire dalla versione 10.11, MariaDB documenta my_print_defaults --mariadbd per questa ricerca. Il nome mariadbd indica il processo del server attuale; mysqld In molte installazioni viene mantenuto come denominazione precedente o come indicazione di compatibilità. Non considerare quindi entrambi i nomi come indicazione della stessa versione concreta del server o dello stesso nome del servizio.

Se il log si trova nel journal di systemd, restringi l'intervallo di tempo utilizzando il nome dell'unità verificato sul sistema. Se necessario, controlla anche il file dell'unità e i drop-in presenti, in modo da non tralasciare eventuali parametri di avvio aggiuntivi. Aggiungi quindi al frammento il log dell'applicazione relativo allo stesso periodo, qualora il sintomo si manifesti in un'applicazione.

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

Classificare i livelli e gli errori iniziali

Le etichette strutturano il log degli errori di MariaDB, ma non sostituiscono l'analisi delle cause. Una Gravità descrive la classificazione di una riga, non necessariamente il danno o l’urgenza. Proprio in caso di un problema di avvio, è l’ordine a fare la differenza: un messaggio di errore concreto apparso in precedenza spesso spiega uno successivo Aborting, mentre le note che precedono possono anche descrivere l'inizializzazione standard.

Se MariaDB non si avvia, individua innanzitutto l'ultima sequenza di avvio nel log e poi leggila a ritroso. Cerca in particolare unknown variable, file mancanti o illeggibili, problemi di autorizzazione ed errori nell'inizializzazione dei plugin. MariaDB indica il registro degli errori (Error Log) come fonte primaria per gli avvii non riusciti; in caso di avvio manuale, la causa può essere visualizzata anche sulla console.

A Errore di configurazione di solito riguarda un'opzione sconosciuta, un errore di ortografia o un valore non corretto in un file importato. Verifica quindi innanzitutto le opzioni attive e la corrispondenza delle versioni, invece di modificare i dati. Un errore durante l’apertura di un file di dati o un avviso InnoDB può invece riguardare autorizzazioni, percorsi, memoria o stato dei dati e richiede un’analisi molto più attenta.

Non modificare più parametri contemporaneamente per forzare l'avvio. Salva l'estratto del log e prendi nota di quale modifica ha preceduto l'errore. Solo quando il primo messaggio rilevante è stato associato a un'impostazione o a una risorsa verificata, è possibile pianificare una correzione mirata e tracciabile.

Valutazione diagnostica dei sintomi ricorrenti

Le formulazioni ricorrenti accorciano la ricerca, ma raramente forniscono da sole una diagnosi. Assegna ogni messaggio a un intervallo di tempo, all’host o al thread interessato e al sintomo osservato. La tabella elenca volutamente solo i passi diagnostici successivi: in questo modo si evita di dedurre affrettatamente che la causa risieda nel server del database sulla base di un riferimento a connessioni, file o replica.

All'indirizzo Accesso negato Innanzitutto è fondamentale stabilire per quale utente e host client sia stato rifiutato l'accesso. Verifica la configurazione dell'applicazione utilizzata e l'ora dell'evento, non limitarti a considerare solo la password. Il messaggio può essere causato da credenziali errate, da un riferimento all’host non corretto o da un’autenticazione non valida; non indica che il database sia danneggiato.

A Connessione interrotta può essere dovuto a un timeout dell'applicazione, a un'interruzione della connessione di rete, a un proxy o a un errore nella trasmissione dei pacchetti. Confronta l’host client e l’ID thread con il log dell’applicazione. Per i contatori, utilizza valori globali anziché quelli relativi alla sessione; in caso contrario, una sessione appena riavviata potrebbe mostrare valori erroneamente bassi.

SHOW GLOBAL STATUS LIKE 'Aborted%';

La query mostra i contatori, ma non la causa completa né l’assegnazione a un singolo client. Valuta quindi le variazioni su un arco di tempo adeguato, insieme a estratti del log. In caso di avvisi relativi alla replica o al GTID, documenta anche le righe successive e verifica lo stato della replica utilizzando le informazioni di stato previste a tale scopo; la sola riga del log degli errori non è sufficiente per una diagnosi completa della replica.

Valutare il ripristino di InnoDB senza rischi per i dati

Dopo un arresto imprevisto, potrebbero comparire messaggi quali „Recovering after a crash“, „Starting crash recovery“ e un messaggio di completamento con esito positivo. Questi descrivono innanzitutto un processo automatico di ripristino dopo un crash all’avvio del server. In relazione al Binary Log o tc.log Possono inoltre contenere informazioni relative al coordinamento delle transazioni. Queste righe, di per sé, non costituiscono una prova della presenza di tabelle danneggiate o di perdita di dati.

La valutazione cambia se, dopo il ripristino, si verifica un [ERRORE] se l'avvio si interrompe o se i messaggi segnalano file illeggibili o danneggiati. Leggi quindi l'intera sequenza di avvio in ordine cronologico e prendi nota della versione, del momento in cui si è verificato il guasto e del passaggio completo. Un riferimento al Binary Log o al tc.log, in assenza di errori successivi, non costituisce ancora una richiesta di riparazione.

In caso di un presunto problema relativo ai dati, non si dovrebbero effettuare cancellazioni di file o altri interventi volti esclusivamente a forzare l'avvio. Chiarisci innanzitutto l'obiettivo dell'intervento: circoscrivere l'errore, leggere in modo controllato i dati accessibili o ripristinare un'istanza produttiva. A tal fine, registra separatamente l’estratto del log, i backup disponibili e lo stato dell’istanza interessata.

Se è possibile un’estrazione controllata, il trasferimento in un’istanza di destinazione pulita deve essere pianificato, anziché considerare l’ambiente interessato come risolto. Per comprendere i meccanismi transazionali coinvolti, è utile l’articolo su Log di annullamento di MariaDB per amministratori. In caso di arresti anomali ripetuti o errori di file non chiari, è più opportuno ricorrere a un servizio di recupero dati specializzato piuttosto che continuare a tentare l'avvio.

Distinguere tra replica ed errori SQL

Nel log degli errori, durante i processi di replica possono comparire thread, posizioni, GTID o log di inoltro. Tali informazioni forniscono innanzitutto un contesto per il periodo in questione, ma non costituiscono ancora una diagnosi completa dell’errore. Salva le righe precedenti e successive alla voce e verifica separatamente lo stato della replica. Da una singola riga del log non è possibile dedurre in modo affidabile se un thread sia terminato regolarmente o se si sia verificata un’interruzione.

Notizie su operazioni predisposte Dopo un crash, invece, è necessaria particolare cautela. Un recupero euristico, a seconda dell’opzione scelta, decide se eseguire un commit o un rollback, ignorando le informazioni relative al coordinamento delle transazioni. Non si tratta di una procedura da seguire nella risoluzione generale dei problemi di MySQL, bensì di un caso particolare le cui conseguenze per le repliche e i dati aziendali devono essere valutate in anticipo.

Il registro degli errori (Error Log) registra gli eventi del server, ma non costituisce un registro completo di tutte le istruzioni SQL errate. I registri binari (Binary Logs) servono principalmente a registrare le modifiche e a gestire la replica; il loro ruolo è illustrato nell'articolo su I log binari di MariaDB e la loro logica di prestazione. Lo Slow Query Log è utile in caso di query lente, il General Query Log serve per un monitoraggio completo delle connessioni e delle query, mentre l’Audit Log ha una funzione di controllo diversa.

Per gli errori SQL che si verificano è disponibile il file separato Plugin SQL_ERROR_LOG. Può inoltre registrare gli errori gestiti da un Condition Handler e che, di conseguenza, non vengono tecnicamente trasmessi al client. Il plugin non viene installato automaticamente; a partire da MariaDB 10.11.5, se le impostazioni sono adeguate, è possibile registrare anche gli avvisi. Le sue voci possono contenere dati relativi a utenti e host, nomi di database e testo SQL. Si raccomanda pertanto di definire diritti di accesso restrittivi, procedure di conservazione e rotazione prima di attivare la registrazione aggiuntiva in un ambiente di produzione.

Gestione, escalation e passi successivi

Assicurati in caso di anomalie errori del database innanzitutto un estratto coerente del log con i timestamp, non solo l'ultima riga. Annotare la versione di MariaDB con l’identificativo del pacchetto, il meccanismo di avvio, il sintomo osservato e la correlazione temporale con le operazioni di distribuzione, i riavvii o gli eventi dell’infrastruttura. Questi dati consentono di distinguere una possibile causa dalle sue conseguenze e permettono di confrontare insieme le indicazioni provenienti dall’applicazione, dal sistema operativo e dal database.

Confronta quindi le opzioni effettivamente caricate con la configurazione desiderata, invece di modificare i valori predefiniti presunti. Ciò è particolarmente importante perché il pacchetto, la versione di MariaDB e i nomi di compatibilità possono influire in modo diverso sulle opzioni. Se è presente un errore di configurazione, è possibile pianificarne la risoluzione in modo diverso rispetto a un eventuale danno alla memoria o a InnoDB.

Prima di effettuare riavvii, tentativi di ripristino o modifiche alla configurazione, è opportuno, come misura di sicurezza, verificare la presenza di backup disponibili e la loro utilizzabilità. Documentare inoltre la modifica prevista e un piano di ripiego. Ciò non sostituisce un’analisi delle cause, ma riduce il rischio che un’azione diagnostica nasconda lo stato iniziale o complichi il ripristino.

Un singolo rifiuto di accesso o una connessione interrotta possono essere inizialmente tenuti sotto osservazione, purché non si ripetano e l’applicazione e il servizio rimangano stabili. Se tali eventi si ripetono con frequenza, coinvolgere l’host client, l’applicazione, il proxy e la rete. Ripetuti arresti anomali all’avvio, file di dati illeggibili, operazioni di ripristino dopo un crash fallite o indicazioni relative a transazioni in sospeso sono invece casi che richiedono un’escalation tempestiva con i dati originali salvati.

Anche un registro ben funzionante necessita di regole operative. Monitorare Rotazione del registro e l'utilizzo della memoria, poiché una maggiore verbosità o ulteriori log degli errori SQL possono far aumentare rapidamente le dimensioni dei file. Limita l'accesso ai log, poiché contengono dettagli tecnici e, eventualmente, contenuti riservati delle query. Le modifiche permanenti sono giustificabili solo dopo aver documentato la causa, definito un piano di ripristino e verificato l’impatto sulla protezione dei dati e sulla capacità.