Risoluzione dell'errore Zimbra "DB Error: DB Failure / Corruption" nei log delle caselle di posta: Diagnosi e ripristino sicuri

Il messaggio "Errore DB: Errore DB" nel log di una casella di posta Zimbra è un sintomo, non una diagnosi. Potrebbe indicare un database arrestato, una connessione non riuscita, spazio su disco esaurito, troppe connessioni o un effettivo danneggiamento di tabelle o di InnoDB. La soluzione sicura dipende dalle righe di log circostanti e dal server interessato. Iniziate con controlli in sola lettura, proteggete i dati e non eseguite un comando di riparazione generico solo perché compare la parola "danneggiamento".

Questa guida utilizza percorsi e comandi Zimbra comuni documentati nel Centro assistenza tecnica di Zimbra. Alcune pagine wiki correlate sono contrassegnate come archiviate o incomplete, pertanto si consiglia di verificare ogni comando e procedura di ripristino in base all'edizione e alla versione esatta di Zimbra in uso, consultando l' indice ufficiale della documentazione di Zimbra . Gli esempi seguenti non presuppongono una versione specifica.

Che cosa significa esattamente un errore del database nel file mailbox.log?

Il database delle caselle di posta di Zimbra memorizza i metadati delle caselle di posta, come cartelle, tag, stato dei messaggi e puntatori ai file dei messaggi. Gli indici di ricerca sono memorizzati separatamente e il contenuto dei messaggi è memorizzato nell'archivio dei messaggi. Pertanto, un errore del database non implica automaticamente che tutti i file di posta elettronica siano danneggiati. Né un errore di indice di per sé è prova di un danneggiamento del database. Zimbra descrive questi archivi separati nella documentazione di riferimento sull'architettura del server .

L'indizio decisivo è solitamente l'errore del database sottostante che appare vicino all'eccezione della casella di posta, in particolare in /opt/zimbra/log/mysql_error.log. Le note di risoluzione dei problemi di Zimbra identificano mailbox.loge mysql_error.logcome punti di partenza utili, con che zmmailboxd.outfornisce dettagli sull'avvio del servizio di casella di posta. Consultare il riferimento alla risoluzione dei problemi del log di Zimbra .

Cosa dovresti fare prima di provare una soluzione?

• Registra l'ora della prima occorrenza, il fuso orario, il nome host del server, l'account o gli account interessati e l'eccezione completa, incluse le righe adiacenti. Oscura le password, il contenuto dei messaggi e i dati personali prima di condividere i log.
• Determinare l'ambito: una singola casella di posta, più caselle di posta su un singolo archivio o utenti distribuiti su più archivi. Un sintomo riscontrato su un singolo account non giustifica il riavvio del database a livello di cluster.
• Verificate che esista un backup recente e utilizzabile e individuate la procedura di ripristino specifica per la versione in uso. Se gli errori si ripetono o gli utenti sono effettivamente interessati, evitate riavvii e scritture ripetuti finché non avrete compreso lo stato del database.
• Utilizzate una finestra di manutenzione per i controlli che analizzano le tabelle del database. Anche un semplice controllo di integrità può generare operazioni di I/O e rallentare il servizio di posta elettronica.

Come si diagnostica in modo sicuro?

1. Verificare lo stato del servizio

Sul server di posta, passare all'account Zimbra e verificare lo stato del servizio. Eseguire i comandi come l'account visualizzato in ogni prompt; non incollare simboli di prompt come $parte del comando.

su - zimbra
zmcontrol status

Verifica se la casella di posta è in esecuzione e se il problema segnalato è locale a un singolo server di posta. Un processo della casella di posta arrestato non è sufficiente per concludere che il database sia danneggiato. La pagina di risoluzione dei problemi della casella di posta di Zimbra elenca anche lo stato del servizio e l'accesso/configurazione del database come controlli separati; tale pagina è contrassegnata come archiviata, quindi utilizzala come riferimento e segui la documentazione per la tua versione.

2. Confronta contemporaneamente i log della casella di posta e del database.

Leggete la stessa finestra temporale in entrambi i file di log. Il primo errore della sequenza è spesso più utile della riga finale "errore di sistema".

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

Cerca il messaggio di errore del database sottostante, il nome del database o del gruppo di cassette postali, i timestamp ripetuti, gli errori di avvio o un errore del sistema operativo corrispondente. Considera queste frasi come indizi, non come soluzioni automatiche:

3. Verificare la capacità del disco e gli errori del sistema operativo.

Volumi di dati o di log pieni, inode esauriti o storage difettoso possono sembrare un errore del database. Eseguire controlli non distruttivi sull'host di archiviazione:

df -h /opt/zimbra
df -i /opt/zimbra

Controlla il registro di sistema o il log di sistema per individuare errori di I/O del disco, del file system o di memoria insufficiente nello stesso intervallo di tempo. Se un volume è pieno, libera o aggiungi spazio utilizzando la normale procedura di archiviazione. Non eliminare i file del database, i log di InnoDB o i log attivi di Zimbra per liberare spazio; ciò potrebbe rendere più difficile il ripristino o distruggere le prove.

4. Eseguire un controllo di integrità solo dopo averne valutato l'impatto.

Se il servizio di database di Zimbra è raggiungibile e i log non mostrano già un problema evidente di connessione o di archiviazione, un amministratore può valutare la possibilità di generare un report di integrità standard durante una finestra di manutenzione a basso traffico:

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

La documentazione di Zimbra relativa al report di integrità descrive questa operazione come un controllo del database e avverte che può comportare un aumento delle operazioni di I/O e della latenza della casella di posta. Viene inoltre descritta un'opzione -rper tentare la riparazione automatica della tabella. Non aggiungerla -rcome passaggio successivo di routine: la pagina è contrassegnata come "in fase di elaborazione" e l'azione corretta dipende dal motore del database, dal tipo di tabella, dalla versione del prodotto e dallo stato del backup. Un report che menziona solo un messaggio noto e innocuo di blocco della tabella dei log deve essere interpretato secondo la nota presente nella pagina; non considerare tutte le intestazioni "Errori del database rilevati" allo stesso modo.

Quale soluzione corrisponde alle prove?

• Il servizio del database è arrestato, ma non si riscontrano segni di danneggiamento: risolvere innanzitutto l'errore specifico di avvio, configurazione, credenziali o risorsa. Una volta risolto, utilizzare la procedura di ripristino del servizio specifica per la propria versione e topologia di distribuzione. Evitare riavvii ripetuti senza una procedura chiara.
• Troppe connessioni: indagare sul carico, sui client bloccati e sulla capacità del servizio. Non etichettare il problema come corruzione del database né copiare una vecchia raccomandazione per aumentare i limiti senza verificare il dimensionamento attuale e le linee guida di rilascio.
• Problema del disco o del filesystem: stabilizzare lo storage e verificare che il filesystem sia integro. Se il database ha registrato errori di scrittura o errori InnoDB, considerarlo come un possibile incidente di integrità anche dopo il ripristino dello spazio.
• Il report di integrità segnala le tabelle: salvare l'output esatto, i nomi delle tabelle/database, i timestamp e i log pertinenti. Eseguire un backup o uno snapshot del volume del database utilizzando un metodo supportato prima di qualsiasi operazione di scrittura. Chiedere a un amministratore di seguire la procedura di riparazione o ripristino supportata dal fornitore per la versione di Zimbra installata.
• Un account rimane interessato dal problema, mentre il motore del database è integro: analizza separatamente i metadati della casella di posta, l'archivio dei messaggi o l'indice relativi a tale account. Evita di modificare manualmente le righe SQL o di eliminare file per "ricostruire" l'account.

In caso di sospetta corruzione di InnoDB, la soluzione più sicura è solitamente un ripristino specifico per la release da un backup verificato o un ripristino guidato dall'assistenza, non una REPAIR TABLEreinizializzazione generica del database o una sequenza di comandi copiata. Alcuni vecchi articoli del wiki di Zimbra sul ripristino includono passaggi distruttivi e sono esplicitamente archiviati; non applicarli a un sistema corrente senza conferma diretta dall'assistenza Zimbra e un backup testato.

Come puoi confermare che il problema è stato risolto?

Dopo l'azione correttiva approvata, verificare che i servizi di database e di casella di posta rimangano attivi, che le nuove voci non mostrino più lo stesso errore di database sottostante e che l'account interessato possa eseguire normali operazioni di posta. Eseguire nuovamente il report di integrità standard solo se appropriato per la finestra di caricamento e la versione in uso. Verificare che il processo di backup sia completato e conservare i log e il record di ripristino. Se il problema si ripresenta, comunicare all'amministratore o al canale di supporto Zimbra la versione/build esatta di Zimbra, la configurazione a server singolo o multi-server, l'ambito della casella di posta, l'ora del primo errore, gli estratti di log pertinenti, lo stato del disco, l'output del report di integrità e la data e l'ora del backup.

Punto chiave: diagnosticare l'errore del database alla base dell'eccezione della casella di posta prima di modificare i dati. Il solo messaggio "Errore del database" non è sufficiente per stabilire se la soluzione consiste nella correzione delle credenziali, nella modifica della capacità, nella riparazione dello storage o nel ripristino del database.

Riferimenti principali: Indice della documentazione di Zimbra ; Architettura del server Zimbra ; Risoluzione dei problemi relativi ai log di Zimbra ; Riferimento al report di integrità del database di Zimbra ; Riferimento all'errore MySQL 1040 di Zimbra ; e Riferimento alla risoluzione dei problemi relativi alle caselle di posta di Zimbra . Alcune pagine del Tech Center sono archiviate o contrassegnate come "in fase di sviluppo", come indicato nell'articolo.