Remediați eroarea Zimbra „DB Error: DB Failure / Corruption” în jurnalele cutiei poștale: Diagnosticare și recuperare sigure

„Eroare DB: Eroare DB” într-un jurnal de cutie poștală Zimbra este un simptom, nu un diagnostic. Poate indica o bază de date oprită, o conexiune eșuată, spațiu pe disc epuizat, prea multe conexiuni sau coruperea unui tabel sau a InnoDB. Remedierea sigură depinde de liniile de jurnal înconjurătoare și de serverul afectat. Începeți cu verificări doar pentru citire, protejați datele și nu executați o comandă generică de reparare doar pentru că apare cuvântul „corupție”.

Acest ghid utilizează căi și comenzi Zimbra comune documentate în Centrul Tehnic Zimbra. Unele pagini wiki conexe sunt marcate ca arhivate sau neterminate, așadar confirmați fiecare comandă și procedură de recuperare în raport cu ediția și versiunea exactă de Zimbra utilizând indexul oficial al documentației Zimbra . Exemplele de mai jos nu presupun o versiune specifică.

Ce înseamnă de fapt o eroare a bazei de date în mailbox.log?

Baza de date a cutiilor poștale Zimbra stochează metadatele acestora, cum ar fi foldere, etichete, starea mesajelor și pointeri către fișiere de mesaje. Indexurile de căutare sunt stocate separat, iar conținutul mesajelor este stocat în depozitul de mesaje. Prin urmare, o eroare a bazei de date nu înseamnă automat că fiecare fișier de e-mail este corupt. Nici o eroare de index nu este în sine o dovadă a deteriorării bazei de date. Zimbra descrie aceste depozite separate în referința sa privind arhitectura serverului .

Indiciu decisiv este de obicei eroarea de bază a bazei de date care apare lângă excepția cutiei poștale, în special în /opt/zimbra/log/mysql_error.log. Notele de depanare Zimbra identifică mailbox.logși mysql_error.logca puncte de plecare utile, zmmailboxd.outoferind detalii despre pornirea serviciului de cutii poștale. Consultați referința de depanare a jurnalelor Zimbra .

Ce ar trebui să faci înainte de a încerca o remediere?

• Înregistrați prima oră de apariție, fusul orar, numele de gazdă al serverului, contul sau conturile afectate și excepția completă, plus liniile din apropiere. Ștergeți parolele, conținutul mesajelor și datele personale înainte de a partaja jurnalele.
• Determinați domeniul de aplicare: o cutie poștală, mai multe cutii poștale dintr-un singur magazin sau utilizatori din mai multe magazine. Un simptom specific unui singur cont nu justifică o repornire a bazei de date la nivel de cluster.
• Verificați dacă există o copie de rezervă recentă și utilizabilă și identificați procedura de restaurare specifică versiunii. Dacă erorile se repetă sau utilizatorii sunt afectați în mod activ, evitați repornirile și scrierile repetate până când starea bazei de date este înțeleasă.
• Folosește o fereastră de întreținere pentru verificările care scanează tabelele bazei de date. Chiar și o verificare a integrității poate adăuga I/O și poate încetini serviciul de cutii poștale.

Cum îl diagnostichezi în siguranță?

1. Verificați starea serviciului

Pe serverul de cutii poștale, comutați la contul Zimbra și verificați starea serviciului. Executați comenzile ca și contul afișat în fiecare prompt; nu lipiți un simbol de prompt, cum ar fi $ca parte a comenzii.

su - zimbra
zmcontrol status

Rețineți dacă cutia poștală rulează și dacă problema raportată este locală pentru un server de cutii poștale. Un proces oprit al cutiei poștale nu este suficient pentru a concluziona că baza de date este coruptă. Pagina de depanare a cutiei poștale Zimbra listează, de asemenea, starea serviciului și conectarea/configurarea bazei de date ca verificări separate; acea pagină este marcată ca arhivată, așa că folosiți-o ca fundal și urmați documentația pentru versiunea dvs.

2. Comparați jurnalele cutiei poștale și ale bazei de date în același timp

Citiți aceeași fereastră de timp în ambele jurnale. Prima eroare din secvență este adesea mai utilă decât ultima linie „eroare de sistem”.

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

Căutați mesajul bazei de date subiacente, numele bazei de date sau al grupului de cutii poștale, marcaje temporale repetate, erori de pornire sau o eroare de sistem de operare corespondentă. Tratați aceste fraze ca indicii, nu ca remedieri automate:

3. Verificați capacitatea discului și erorile sistemului de operare

Volumele pline de date sau de jurnal, inodurile epuizate sau stocarea defectă pot părea o eroare a bazei de date. Rulați verificări nedistructive pe gazda depozitului:

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

Verificați jurnalul sistemului de operare sau jurnalul de sistem pentru erori de intrare/ieșire pe disc, sistem de fișiere sau memorie insuficientă în același interval de timp. Dacă un volum este plin, eliberați sau adăugați spațiu utilizând procedura normală de stocare. Nu ștergeți fișierele bazei de date, jurnalele InnoDB sau jurnalele Zimbra active pentru a face loc; acest lucru poate îngreuna recuperarea sau poate distruge dovezi.

4. Efectuați o verificare a integrității numai după analizarea impactului

Dacă serviciul de baze de date Zimbra este accesibil și jurnalele nu arată deja o problemă clară de conexiune sau stocare, un administrator poate lua în considerare raportul standard de integritate în timpul unei ferestre de întreținere cu trafic redus:

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

Referința raportului de integritate din Zimbra descrie acest lucru ca o verificare a bazei de date și avertizează că poate adăuga intrări/ieșiri și poate crește latența cutiei poștale. De asemenea, documentează o -ropțiune ca încercare de reparare automată a tabelului. Nu adăugați -rca pas următor de rutină: pagina este marcată ca lucru în curs, iar acțiunea corectă depinde de motorul bazei de date, tipul tabelului, versiunea produsului și starea copiei de rezervă. Un raport care menționează doar un mesaj cunoscut de blocare a tabelului de jurnal inofensiv trebuie interpretat conform notei de pe pagina respectivă; nu tratați fiecare antet „Erori în baza de date găsite” ca fiind egal.

Care soluție corespunde dovezilor?

• Serviciul bazei de date este oprit, dar nu apar dovezi de corupere: remediați mai întâi eroarea specifică de pornire, configurare, acreditare sau resursă. După corectare, utilizați procedura de recuperare a serviciului pentru topologia de lansare și implementare. Evitați repornirile repetate fără semnal.
• Prea multe conexiuni: investigați încărcarea, clienții blocați și capacitatea serviciului. Nu etichetați-o drept corupție a bazei de date și nu copiați o recomandare veche de a crește limitele fără a verifica instrucțiunile actuale privind dimensionarea și lansarea.
• Problemă cu discul sau sistemul de fișiere: stabilizați spațiul de stocare și confirmați că sistemul de fișiere este sănătos. Dacă baza de date a înregistrat scrieri eșuate sau erori InnoDB, tratați acest lucru ca un posibil incident de integritate chiar și după restaurarea spațiului.
• Raportul de integritate marchează tabelele: salvați ieșirea exactă, numele tabelelor/bazelor de date, marcajele temporale și jurnalele relevante. Faceți o copie de rezervă sau o instantanee a volumului bazei de date utilizând o metodă acceptată înainte de orice operațiune de scriere. Solicitați unui administrator să urmeze procedura de reparare sau restaurare acceptată de furnizor pentru versiunea instalată de Zimbra.
• Un cont rămâne afectat cât timp motorul bazei de date este funcțional: investigați separat metadatele cutiei poștale, depozitul de mesaje sau indexul. Evitați editarea manuală a rândurilor SQL sau ștergerea fișierelor pentru a „reconstrui” contul.

Pentru suspiciunile de corupere a InnoDB, cea mai sigură reparare este de obicei o recuperare specifică versiunii dintr-o copie de rezervă verificată sau o recuperare ghidată de asistență, nu o REPAIR TABLEreinițializare generică a bazei de date sau o secvență de comenzi copiată. Unele articole vechi despre recuperarea wiki Zimbra includ pași distructivi și sunt arhivate explicit; nu le aplicați unui sistem curent fără confirmarea directă din partea asistenței Zimbra și a unei copii de rezervă testate.

Cum puteți confirma că problema este rezolvată?

După acțiunea corectivă aprobată, confirmați că baza de date și serviciile cutiei poștale rămân active, că noile intrări nu mai afișează aceeași eroare subiacentă a bazei de date și că contul afectat poate efectua operațiuni obișnuite de e-mail. Rulați din nou raportul standard de integritate numai dacă este cazul pentru fereastra de încărcare și versiune. Confirmați că lucrarea de backup este finalizată și păstrați jurnalele și înregistrarea reparației. Dacă problema reapare, raportați administratorului sau canalului de asistență Zimbra versiunea/compilarea exactă a Zimbra, aspectul cu un singur server sau cu mai multe servere, domeniul de aplicare al cutiei poștale, ora primei erori, extrase relevante din jurnal, starea discului, rezultatul raportului de integritate și marcajul temporal al backup-ului.

Punct cheie: diagnosticați eroarea bazei de date din spatele excepției cutiei poștale înainte de a modifica datele. „Eșecul bazei de date” nu vă poate spune dacă remedierea este o corecție a acreditărilor, o modificare a capacității, o reparare a spațiului de stocare sau o recuperare a bazei de date.

Referințe principale: Indexul documentației Zimbra ; Arhitectura serverului Zimbra ; Depanarea jurnalelor Zimbra ; Referință raport de integritate a bazei de date Zimbra ; Referință eroare 1040 MySQL Zimbra ; și Referință depanare cutie poștală Zimbra . Unele pagini ale Centrului Tehnic sunt arhivate sau marcate ca fiind în lucru, așa cum se menționează în articol.