Jakie są oznaki ostrzegawcze, że kontener bazy danych został uszkodzony wskutek utraty zasilania?

Podejrzewaj uszkodzenie, gdy baza danych nie może ukończyć standardowego odzyskiwania po awarii lub później zgłasza niespójności sum kontrolnych, stron, sekwencji logów, tabel albo indeksów.

Nieprawidłowe zamknięcie nie oznacza automatycznie, że baza danych jest uszkodzona; PostgreSQL, MySQL, MariaDB i podobne silniki używają dzienników lub dzienników zapisu z wyprzedzeniem właśnie po to, aby odzyskać zatwierdzony stan. Sygnałem ostrzegawczym jest powtarzające się odzyskiwanie, zamykanie silnika, trafianie tego samego zapytania na nieprawidłowe strony, błędy sum kontrolnych, znikające tabele, sprzeczność indeksów z danymi tabel albo niemożność spójnego odczytu klastra przez kopie zapasowe i kontrole integralności.

Odróżnij standardowe odzyskiwanie po awarii od pętli odzyskiwania

Zachowaj pierwszy log uruchomieniowy po powrocie zasilania. Zapisz, czy silnik odtwarza logi jeden raz i staje się gotowy, czy też wielokrotnie uruchamia się ponownie, przechodzi w wymuszone odzyskiwanie albo zatrzymuje się na tym samym rekordzie lub stronie.

InnoDB może zgłosić odtwarzanie potencjalnie częściowo zapisanych stron po przerwanym zapisie; komunikat oznacza, że silnik próbuje bezpiecznie odzyskać stan po awarii, ale powtarzające się błędy mogą wskazywać na błędy InnoDB po awarii zasilania.

Jednorazowe pomyślne odzyskanie, po którym standardowe kontrole przebiegają prawidłowo, nie jest dowodem braku uszkodzeń. Pętla, krytyczne asercje, powtarzające się sygnały lub niemożność osiągnięcia stanu gotowości to sygnał, aby zatrzymać kopiowanie surowych plików i testowanie kopii zapasowych przed wykonaniem kolejnych zapisów.

Szukaj błędów sum kontrolnych i nieprawidłowych stron

Przeszukaj logi pod kątem komunikatów: niezgodność sumy kontrolnej, weryfikacja strony nie powiodła się, nieprawidłowa strona w bloku, uszkodzona strona, niepełny odczyt, nieprawidłowy numer magiczny lub nieoczekiwany koniec pliku. Zapisz wskazaną relację, tabelę, blok albo przestrzeń tabel.

pganalyze pokazuje, że uszkodzenie PostgreSQL ujawnia się jako błędy sum kontrolnych stron, po których pojawia się błąd nieprawidłowej strony podczas odczytu uszkodzonego bloku.

Nie wyciszaj błędu ani nie zeruj uszkodzonych stron przed zabezpieczeniem dowodów i potwierdzeniem zakresu kopii zapasowych. Ten sam blok, który nie przechodzi kontroli po każdym ponownym uruchomieniu, jest mocniejszym dowodem niż jednorazowe przekroczenie limitu czasu aplikacji.

Obserwuj zapytania, które kończą się błędem tylko dla określonych wierszy lub tabel

Wykonuj kontrole tylko do odczytu na tabelach i zapytaniach używanych zwykle przez aplikację. Uszkodzenie może pozostać ukryte do momentu, gdy skanowanie, odkurzanie, kopia zapasowa lub żądanie dotknie uszkodzonej strony.

Analiza PostgreSQL wyjaśnia, że niezgodność sumy kontrolnej wskazuje na problem poza bazą danych, natomiast nieprawidłowa strona bez ostrzeżenia o sumie kontrolnej nadal może oznaczać problemy z pamięcią masową, pamięcią operacyjną, systemem plików lub przypadkowe uszkodzenie pliku. Praktycznym objawem jest powtarzalny odczyt nieprawidłowej strony podczas zwykłych zapytań.

Zapisz dokładnie, które zapytanie i obiekt kończą się błędem. Nie pozwalaj aplikacji kontynuować masowych zapisów, gdy tylko część bazy pozostaje dostępna do odczytu, ponieważ nowy stan może utrudnić odzyskiwanie i tworzenie kopii zapasowych.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź niespójności indeksów, transakcji i metadanych

Do sygnałów ostrzegawczych należą zduplikowane klucze naruszające unikatowy indeks, brakujące wiersze dostępne jedną ścieżką dostępu, ale nie inną, nieprawidłowe identyfikatory transakcji, uszkodzone fragmenty TOAST lub dużych wartości oraz indeksy, które nie przechodzą walidacji.

Przegląd uszkodzeń przeprowadzony przez Credativ wskazuje, że klastry bez sum kontrolnych danych mogą ujawniać uszkodzenia przez błędy niskiego poziomu, takie jak nieprawidłowe strony, problemy z identyfikatorami transakcji, niespójności TOAST lub awarie backendu. Niektóre kopie zapasowe wykonywane przez kopiowanie plików mogą zachować uszkodzone strony bez ich wykrycia.

Wykonuj obsługiwane kontrole integralności i indeksów na kopii lub w kontrolowanym oknie serwisowym. Odbudowa indeksu może naprawić uszkodzony indeks pochodny, ale nie naprawi uszkodzonych danych tabel ani podstawowej pamięci masowej.

Powiąż błędy bazy danych z ostrzeżeniami systemu plików i pamięci masowej

Sprawdź logi jądra hosta, systemu plików, puli, dysków, kontrolera, zasilacza UPS i środowiska uruchomieniowego kontenerów z czasu awarii. Szukaj błędów wejścia-wyjścia, resetów, błędów sum kontrolnych, ponownego montowania w trybie tylko do odczytu, zdegradowanych pul oraz utraconych lub obciętych plików.

Przewodnik odzyskiwania bazy danych wskazuje, że awarie zasilania i wadliwa pamięć mogą powodować uszkodzone zapisy stron, szczególnie gdy zachowanie pamięci masowej nie odpowiada założeniom bazy danych dotyczącym trwałości. Zdarzenia na poziomie hosta pomagają odróżnić uszkodzenie stron InnoDB od zwykłego ponownego uruchomienia aplikacji.

Napraw ścieżkę pamięci masowej przed przywróceniem na niej sprawnej bazy danych. Pomyślne logiczne przywrócenie na uszkodzonym nośniku może powtórzyć incydent lub po cichu uszkodzić zamiennik.

Zatrzymaj zapisy i potwierdź odzyskiwanie z czystej kopii zapasowej

Gdy oznaki uszkodzenia są powtarzalne, zatrzymaj zależne aplikacje, wykonaj migawkę lub klon dotkniętego woluminu, jeśli jest to bezpieczne, oraz zabezpiecz logi i konfigurację. Przetestuj najnowszą kopię zapasową na oddzielnej pamięci masowej przed modyfikacją oryginalnego klastra.

Lista kontrolna ZimaSpace dotycząca tworzenia kopii zapasowej stanu aplikacji Docker określa, co musi istnieć przed destrukcyjną próbą odzyskania bazy danych.

System jest godny zaufania dopiero wtedy, gdy przywrócona baza danych uruchamia się bez błędów, kontrole integralności przechodzą pomyślnie, reprezentatywne zapytania i zapisy działają, kopie zapasowe kończą się powodzeniem, a pamięć masowa hosta nie zgłasza nowych błędów. Tryby wymuszonego odzyskiwania należy stosować do ratowania danych w ramach udokumentowanego planu odzyskiwania, a nie podczas normalnej pracy.