Remediați corupția indexului de căutare Zimbra: Cum să reindexați o cutie poștală

Revizuit la 6 octombrie 2026. Dacă căutarea Zimbra returnează rezultate incomplete pentru o cutie poștală și jurnalul cutiei poștale indică o eroare de indexare sau Lucene, repararea obișnuită este reconstruirea indexului de căutare al acelei cutii poștale cu zmprov rim account@example.com start. Comanda recreează datele indexului căutabile din conținutul cutiei poștale; nu este o reparare pentru fișierele de mesaje lipsă, coruperea bazei de date, un volum de stocare complet sau erori de căutare la nivel de server.

Judecă succesul după rezultatul real: jobul de reindexare se termină, căutările direcționate returnează mesaje care lipseau anterior, iar mesajele noi continuă să apară în căutare. Pornirea comenzii nu este o dovadă că indexul este reconstruit. Planifică lucrul într-o perioadă mai liniștită, verifică mai întâi volumul indexului și rulează-l pentru un cont afectat înainte de a extinde domeniul de aplicare.

Când este reindexarea cutiei poștale soluția corectă?

Un index deteriorat sau incomplet este o suspiciune rezonabilă atunci când accesul obișnuit la cutia poștală funcționează, dar căutările ratează mesajele cunoscute, un utilizator afectat vede rezultate de căutare inconsistente sau /opt/zimbra/log/mailbox.lograportează mesaje precum „Deschiderea indexului a eșuat” sau o excepție Lucene pentru contul respectiv. Materialul de depanare Zimbra documentează zmprov verifyIndexca diagnostic un index care lipsește sau nu poate fi deschis și îl folosește zmprov rim ... startpentru a-l recrea.

Mai întâi stabiliți domeniul de aplicare. Dacă este afectat un singur utilizator, investigați acea cutie poștală. Dacă mai mulți utilizatori din același depozit de mailuri au același simptom, verificați starea serverului, capacitatea de stocare, actualizările recente și jurnalele înainte de a lansa mai multe reconstruiri. Un lot mare de reindexări poate consuma o cantitate substanțială de I/O pe disc și CPU și poate agrava căutarea lentă pentru alți utilizatori.

O reindexare nu este prima mișcare corectă atunci când utilizatorii nu se pot conecta, lipsesc foldere, corpurile mesajelor sau atașamentele nu se deschid, baza de date a depozitului de mailuri raportează erori sau serviciul de căutare nu este disponibil pentru mai multe conturi. Aceste semne pot indica probleme legate de baza de date, depozitul de blob-uri, serviciu sau infrastructură. Păstrați jurnalele și utilizați procedura de recuperare sau canalul de asistență Zimbra corespunzător în loc să tratați fiecare reclamație de „căutare” ca fiind o corupere a indexului.

Înainte de a executa comanda

• Confirmați cutia poștală țintă: Copiați adresa contului principal, nu un alias. Într-o implementare cu mai multe depozite de e-mail, verificați care server de cutii poștale deține contul și executați comanda în funcție de topologia și versiunea Zimbra instalată.
• Verificați spațiul disponibil: Inspectați spațiul liber și inode-urile de pe volumul de indexare real. Instalările pot plasa datele de indexare pe o montare separată; nu presupuneți că calea implicită este locația activă. Un volum de indexare plin poate cauza în sine erori de indexare.
• Verificați încărcarea sistemului: Notați latența curentă a depozitului de e-mail, activitatea procesorului și a discului. Reindexarea necesită resurse mari, în special pentru cutiile poștale mari, așa că programați-o departe de perioada de vârf a traficului.
• Protejați recuperabilitatea: Verificați dacă procesul normal de backup este sănătos și recent înainte de întreținere. Reindexarea are scopul de a reconstrui datele de căutare derivate, dar o copie de rezervă rămâne importantă înainte de orice lucrări de reparare a e-mailului de producție.
• Verificați suportul pentru comenzi: Sintaxa CLI a Zimbra și opțiunile disponibile pot varia în funcție de versiune. Consultați ajutorul și documentația comenzilor pentru versiunea instalată exactă, mai ales dacă utilizați o versiune mai veche sau o implementare personalizată.

Cum se verifică și se reconstruiește o cutie poștală

1. Efectuați o verificare diagnostică, dacă este disponibilă

În calitate de cont al sistemului de operare Zimbra, testați cutia poștală suspectată cu ajutorul diagnosticului prezentat în ghidul de depanare Zimbra:

zmprov verifyIndex user@example.com

Un răspuns care indică faptul că indexul nu există sau că un fișier segment nu poate fi găsit acceptă diagnosticul de corupere a indexului. Dacă versiunea instalată nu recunoaște verifyIndex, nu instalați scripturi și nu copiați fișiere index de pe alt server pentru a ocoli acest lucru. Utilizați documentația Zimbra specifică versiunii și corelați jurnalul cutiei poștale cu contul afectat.

2. Porniți reindexarea cutiei poștale

Pe serverul Zimbra corespunzător, comutați la contul sistemului de operare Zimbra și începeți reconstrucția pentru singura cutie poștală afectată:

su - zimbra
zmprov rim user@example.com start

Comanda raportează în mod normal că sarcina a început. Aceasta confirmă trimiterea, nu finalizarea. Nu porniți sarcini repetate doar pentru că căutarea rămâne incompletă imediat după aceea; verificați mai întâi starea sarcinii și jurnalele depozitului de mailuri.

3. Verificați progresul

Interogați sarcina de reindexare folosind același cont și context de server:

zmprov rim user@example.com status

Repetați la un interval rezonabil, în loc să faceți sondaje continue. Citiți răspunsul conform versiunii Zimbra: CLI raportează starea jobului, în timp ce mailbox.logpoate oferi progresul sau erorile specifice contului. Dacă comanda raportează o eroare, sarcina nu se finalizează niciodată sau jurnalele arată erori legate de spațiul pe disc sau de index writer, întrerupeți și rezolvați problema subiacentă înainte de a încerca din nou.

Referința comenzilor Zimbra listează acțiunile reIndexMailboxcu start, status, și cancel. Dacă versiunea dvs. acceptă anularea și jobul dăunează serviciului, confirmați sintaxa locală înainte de a o utiliza. Nu închideți procesele Java și nu eliminați fișierele index ca înlocuitor pentru o procedură de anulare acceptată.

Cum să confirmi că reparația a funcționat

După finalizarea sarcinii, testați din clientul web al utilizatorului afectat cu câteva mesaje cunoscute. Căutați un expeditor distinct, o expresie de subiect și un interval de date; verificați atât mesajele vechi, cât și cele recente. Verificați folderele în care ar trebui să apară mesajele și comparați rezultatul cu un mesaj cunoscut pe care utilizatorul îl poate deschide direct. Apoi trimiteți sau primiți un mesaj de test și confirmați că acesta devine căutabil după întârzierea normală de indexare.

Căutați o îmbunătățire susținută, mai degrabă decât o singură interogare reușită. Criteriile practice de succes sunt:

• Starea de reindexare a cutiei poștale ajunge la finalizare fără erori recurente.
• Mesajele cunoscute, care lipseau anterior, apar în căutările așteptate.
• Noile mesaje continuă să intre în indexul de căutare.
• Volumul de indexare păstrează o capacitate liberă adecvată, iar alte cutii poștale rămân receptive.

Dacă comanda raportează finalizarea, dar anumite mesaje rămân absente, verificați dacă mesajele există încă și pot fi deschise. Verificați dacă termenii de căutare ai utilizatorului, filtrele de dată, domeniul de aplicare al folderului sau memoria cache din partea clientului explică diferența. Un index reconstruit nu poate restaura mesajele care au fost șterse, nu au fost livrate niciodată sau au fost pierdute din depozitul subiacent.

Când să schimbi calea de depanare

Dacă reconstrucția eșuează în mod repetat, remediați mai întâi eroarea menționată în jurnale. Confirmați spațiul pe disc disponibil și inode-urile, verificați dacă există erori mai ample în depozitul de mailuri sau baza de date și asigurați-vă că cutia poștală este gestionată pe serverul corect. Dacă contul nu poate accesa conținutul mesajului sau alte cutii poștale prezintă aceeași problemă, opriți repetarea reindexării și investigați cauza la nivel de depozit, bază de date sau server.

Evitați ștergerea manuală /opt/zimbra/indexa datelor ca pas de rutină. Wiki-ul public al Zimbra include o procedură manuală de eliminare a fișierelor index, dar pagina respectivă este marcată ca fiind în lucru și este legată de versiuni mai vechi. Ștergerea manuală este mai predispusă la erori decât comanda de reindexare la nivel de cont acceptată și ar trebui luată în considerare doar în conformitate cu îndrumările furnizorului actual, specifice versiunii, cu o cale exactă către cutia poștală, copii de rezervă verificate și un plan de întreținere.

Limitele reindexării cutiilor poștale

Reindexarea reconstruiește metadatele căutării; nu repară tabelele MySQL sau MariaDB, nu restaurează blob-urile lipsă, nu corectează un sistem de fișiere deteriorat, nu eliberează un disc complet și nu corectează o întrerupere a căutării la nivel de server. De asemenea, durează mai mult pe măsură ce dimensiunea cutiei poștale și încărcarea serverului cresc. Căutarea poate fi temporar incompletă în timpul indexării, iar performanța generală poate scădea în timpul sarcinii.

Folosește mai întâi reindexarea încorporată la nivel de cutie poștală atunci când dovezile indică indexul de căutare al unui cont. Măsoară rezultatul folosind mesaje cunoscute și e-mailuri ulterioare. Dacă reindexarea nu se poate finaliza sau datele în sine sunt deteriorate, trece la procedura relevantă de stocare sau de recuperare a bazei de date, în loc să escaladezi la ștergerea generală a indexului.

Referințe oficiale

• Referință comandă Zimbra zmprov — listează reIndexMailboxcomanda și sintaxa acțiunilor sale; pagina îi direcționează, de asemenea, pe cititori către Ghidul administratorului pentru detalii specifice versiunii.
• Exemplu de depanare Zimbra pentru un index de cutie poștală corupt — se afișează verifyIndexși comanda de reindexare la nivel de cont. Pagina este marcată ca fiind în lucru, așadar confirmați aplicabilitatea la versiunea instalată.
• Procedura wiki Zimbra care discută despre eliminarea datelor index și verificările de stare — o referință mai veche, în lucru; folosiți-o ca context, nu ca motiv pentru ștergerea fișierelor dintr-un sistem de producție curent.