Napraw błąd Zimbra „Błąd bazy danych: awaria/uszkodzenie bazy danych” w dziennikach skrzynki pocztowej: bezpieczna diagnostyka i odzyskiwanie

Komunikat „Błąd bazy danych: Awaria bazy danych” w logu skrzynki pocztowej Zimbra to objaw, a nie diagnoza. Może on wskazywać na zatrzymanie bazy danych, nieudane połączenie, wyczerpanie miejsca na dysku, zbyt wiele połączeń lub uszkodzenie tabeli lub bazy danych InnoDB. Bezpieczne rozwiązanie zależy od otaczających wierszy logu i serwera, którego dotyczy problem. Zacznij od sprawdzania w trybie tylko do odczytu, chroń dane i nie uruchamiaj ogólnego polecenia naprawy tylko dlatego, że pojawia się słowo „uszkodzenie”.

W tym przewodniku wykorzystano typowe ścieżki i polecenia Zimbra udokumentowane w Centrum Technicznym Zimbra. Niektóre powiązane strony wiki są oznaczone jako zarchiwizowane lub niedokończone, dlatego należy sprawdzić każde polecenie i procedurę odzyskiwania pod kątem konkretnej edycji i wydania Zimbra, korzystając z oficjalnego indeksu dokumentacji Zimbra . Poniższe przykłady nie zakładają konkretnej wersji.

Co tak naprawdę oznacza błąd bazy danych w mailbox.log?

Baza danych skrzynek pocztowych Zimbra przechowuje metadane skrzynek pocztowych, takie jak foldery, tagi, stan wiadomości i wskaźniki do plików wiadomości. Indeksy wyszukiwania są przechowywane oddzielnie, a treść wiadomości jest przechowywana w magazynie wiadomości. Błąd bazy danych nie oznacza zatem automatycznie, że każdy plik wiadomości e-mail jest uszkodzony. Sam błąd indeksu również nie jest dowodem na uszkodzenie bazy danych. Zimbra opisuje te oddzielne magazyny w swoim dokumencie referencyjnym dotyczącym architektury serwera .

Decydującą wskazówką jest zazwyczaj błąd bazy danych, który pojawia się w pobliżu wyjątku skrzynki pocztowej, szczególnie w /opt/zimbra/log/mysql_error.log. Notatki dotyczące rozwiązywania problemów Zimbra identyfikują mailbox.logi mysql_error.logjako przydatne punkty wyjścia, zmmailboxd.outpodając szczegóły uruchamiania usługi skrzynki pocztowej. Zobacz odnośnik do dziennika rozwiązywania problemów Zimbra .

Co należy zrobić przed podjęciem próby naprawy?

• Zapisz czas pierwszego wystąpienia, strefę czasową, nazwę hosta serwera, konto lub konta, których dotyczy problem, oraz pełny wyjątek i pobliskie wiersze. Usuń hasła, treść wiadomości i dane osobowe przed udostępnieniem logów.
• Określ zakres: jedna skrzynka pocztowa, wiele skrzynek pocztowych w jednym sklepie lub użytkownicy w wielu sklepach. Symptom pojedynczego konta nie uzasadnia ponownego uruchomienia bazy danych w całym klastrze.
• Sprawdź, czy istnieje aktualna, użyteczna kopia zapasowa i zidentyfikuj procedurę przywracania dla danej wersji. Jeśli błędy się powtarzają lub użytkownicy są aktywnie dotknięci, unikaj wielokrotnych restartów i zapisów, dopóki stan bazy danych nie zostanie poznany.
• Użyj okna konserwacyjnego do kontroli, które skanują tabele bazy danych. Nawet kontrola integralności może zwiększyć liczbę operacji wejścia/wyjścia i spowolnić działanie skrzynki pocztowej.

Jak bezpiecznie zdiagnozować chorobę?

1. Sprawdź stan usługi

Na serwerze pocztowym przełącz się na konto Zimbra i sprawdź stan usługi. Uruchom polecenia z konta wskazanego w każdym wierszu poleceń; nie wklejaj symbolu wiersza poleceń, np. jako $części polecenia.

su - zimbra
zmcontrol status

Sprawdź, czy skrzynka pocztowa jest uruchomiona i czy zgłoszony problem dotyczy tylko jednego serwera pocztowego. Zatrzymanie procesu skrzynki pocztowej nie wystarczy, aby stwierdzić uszkodzenie bazy danych. Strona rozwiązywania problemów ze skrzynką pocztową Zimbra zawiera również status usługi oraz logowanie/konfigurację bazy danych jako oddzielne kontrole; ta strona jest oznaczona jako archiwalna, więc użyj jej jako tła i postępuj zgodnie z dokumentacją dotyczącą swojego wydania.

2. Porównaj jednocześnie logi skrzynek pocztowych i baz danych

Odczytaj ten sam przedział czasowy w obu logach. Pierwszy błąd w sekwencji jest często bardziej przydatny niż ostatnia linia z informacją o „awarii systemu”.

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

Poszukaj komunikatu bazy danych, nazwy bazy danych lub grupy skrzynek pocztowych, powtarzających się znaczników czasu, błędów uruchamiania lub pasującego błędu systemu operacyjnego. Potraktuj te frazy jako wskazówki, a nie automatyczne rozwiązania:

3. Sprawdź pojemność dysku i błędy systemu operacyjnego

Pełne woluminy danych lub dzienników, wyczerpane inody lub awaria pamięci masowej mogą przypominać awarię bazy danych. Przeprowadź nieniszczące kontrole na hoście magazynu:

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

Sprawdź dziennik systemu operacyjnego lub dziennik systemowy pod kątem błędów wejścia/wyjścia dysku, systemu plików lub braku pamięci w tym samym okresie. Jeśli wolumin jest pełny, zwolnij lub dodaj miejsce, korzystając ze standardowej procedury przechowywania danych. Nie usuwaj plików bazy danych, dzienników InnoDB ani aktywnych dzienników Zimbra, aby zwolnić miejsce; może to utrudnić odzyskiwanie lub spowodować zniszczenie dowodów.

4. Przeprowadź kontrolę integralności dopiero po sprawdzeniu wpływu

Jeśli usługa bazy danych Zimbra jest dostępna, a logi nie wskazują na wyraźny problem z połączeniem lub pamięcią masową, administrator może rozważyć wyświetlenie standardowego raportu dotyczącego integralności podczas okna konserwacji o niskim ruchu:

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

W raporcie integralności Zimbra opisano to jako sprawdzenie bazy danych i ostrzeżono, że może to zwiększyć liczbę operacji wejścia/wyjścia i opóźnienie w działaniu skrzynki pocztowej. Dokumentowano również opcję -rpróby automatycznej naprawy tabeli. Nie należy dodawać tego -rjako rutynowego kroku: strona jest oznaczona jako „praca w toku”, a właściwe działanie zależy od silnika bazy danych, typu tabeli, wersji produktu i stanu kopii zapasowej. Raport, który wspomina tylko o znanym, nieszkodliwym komunikacie o zablokowaniu tabeli dziennika, należy interpretować zgodnie z uwagą na tej stronie; nie należy traktować każdego nagłówka „Znaleziono błędy w bazie danych” jako równorzędnego.

Które rozwiązanie jest zgodne z dowodami?

• Usługa bazy danych została zatrzymana, ale nie pojawiły się żadne oznaki uszkodzenia: najpierw rozwiąż konkretny błąd uruchamiania, konfiguracji, poświadczeń lub zasobów. Po usunięciu usterki skorzystaj z procedury odzyskiwania usługi dla swojej topologii wydania i wdrożenia. Unikaj wielokrotnych restartów bez wiedzy użytkownika.
• Zbyt wiele połączeń: sprawdź obciążenie, zablokowanych klientów i przepustowość usługi. Nie oznaczaj tego jako uszkodzenia bazy danych ani nie kopiuj starego zalecenia podniesienia limitów bez sprawdzenia aktualnych rozmiarów i wytycznych dotyczących wydania.
• Problem z dyskiem lub systemem plików: ustabilizuj pamięć masową i upewnij się, że system plików jest sprawny. Jeśli baza danych zarejestrowała nieudane zapisy lub błędy InnoDB, potraktuj to jako potencjalne naruszenie integralności, nawet po przywróceniu miejsca na dysku.
• Raport integralności oznacza flagami tabele: zapisz dokładne dane wyjściowe, nazwy tabel/baz danych, znaczniki czasu i odpowiednie logi. Przed każdą operacją zapisu utwórz kopię zapasową lub migawkę woluminu bazy danych, używając obsługiwanej metody. Poproś administratora o wykonanie procedury naprawy lub przywracania zalecanej przez dostawcę dla zainstalowanej wersji Zimbra.
• Jedno konto pozostaje zagrożone, dopóki silnik bazy danych działa prawidłowo: sprawdź osobno jego metadane skrzynki pocztowej, magazyn wiadomości lub indeks. Unikaj ręcznej edycji wierszy SQL lub usuwania plików w celu „odbudowania” konta.

W przypadku podejrzenia uszkodzenia InnoDB najbezpieczniejszą metodą naprawy jest zazwyczaj odzyskiwanie danych specyficzne dla danej wersji z zweryfikowanej kopii zapasowej lub odzyskiwanie wspomagane przez dział wsparcia, a nie generyczna REPAIR TABLEponowna inicjalizacja bazy danych lub skopiowana sekwencja poleceń. Niektóre stare artykuły na wiki Zimbra dotyczące odzyskiwania danych zawierają kroki destrukcyjne i są jawnie archiwizowane; nie należy ich stosować w bieżącym systemie bez bezpośredniego potwierdzenia ze strony działu wsparcia Zimbra i przetestowanej kopii zapasowej.

Jak można potwierdzić, że problem został rozwiązany?

Po zatwierdzeniu działań naprawczych należy sprawdzić, czy usługi bazy danych i skrzynki pocztowej nadal działają, czy nowe wpisy nie wskazują już tego samego błędu bazy danych oraz czy konto, którego dotyczy problem, może wykonywać standardowe operacje pocztowe. Ponownie uruchom standardowy raport integralności tylko wtedy, gdy jest to odpowiednie dla danego okna ładowania i wersji. Potwierdź, że zadanie tworzenia kopii zapasowej zostało zakończone i zachowaj dzienniki oraz rekord naprawy. Jeśli problem powróci, przekaż administratorowi lub kanałowi wsparcia Zimbra dokładną wersję/kompilację, układ pojedynczego lub wielu serwerów, zakres skrzynki pocztowej, czas pierwszej awarii, odpowiednie fragmenty dziennika, stan dysku, wynik raportu integralności oraz znacznik czasu kopii zapasowej.

Kluczowa kwestia: przed zmianą danych należy zdiagnozować błąd bazy danych powodujący wyjątek skrzynki pocztowej. Sam komunikat „Błąd bazy danych” nie powie Ci, czy naprawa polega na korekcie danych uwierzytelniających, zmianie pojemności, naprawie pamięci masowej czy odzyskaniu bazy danych.

Główne źródła: indeks dokumentacji Zimbra ; architektura serwera Zimbra ; rozwiązywanie problemów z logami Zimbra ; odniesienie do raportu integralności bazy danych Zimbra ; odniesienie do błędu MySQL 1040 Zimbra ; oraz odniesienie do rozwiązywania problemów ze skrzynką pocztową Zimbra . Niektóre strony Centrum Technicznego są zarchiwizowane lub oznaczone jako prace w toku, jak zaznaczono w artykule.