Sprawdzanie integralności danych po odtworzeniu

Odtwarzanie bazy — to nie zawsze bułka z masłem: niby wszystko poszło OK, ale potem w logach pojawiają się błędy, jakieś tabele znikają albo dane wyglądają podejrzanie. Dlatego tak ważne jest, żeby po odtworzeniu koniecznie sprawdzić, czy wszystko faktycznie gra.

Czasem część danych po prostu się nie odtworzy — na przykład, jeśli backup był uszkodzony. Bywa, że struktura tabel się rozjeżdża: znikają klucze obce, giną indeksy albo pojawiają się dziwne wartości. I nawet jeśli na pierwszy rzut oka wszystko wygląda OK, logi mogą sugerować, że baza wcale nie jest w pełni zdrowa.

Sprawdzanie integralności — to jak przegląd techniczny po naprawie. Lepiej poświęcić chwilę i upewnić się, że wszystko działa, niż potem nagle walczyć z problemem na produkcji.

Analiza logów odtwarzania

Kiedy odtwarzasz dane za pomocą pg_restore, PostgreSQL zawsze generuje log. Log zawiera mnóstwo przydatnych informacji o procesie odtwarzania, w tym ostrzeżenia i błędy. Przykład komendy z podaniem pliku na logi:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Zwróć uwagę na > restore_log.txt 2>&1 — to przekierowuje zarówno standardowe wyjście, jak i błędy do jednego pliku.

Na co patrzeć w logach?

1. Błędy. Zwracaj uwagę na słowa-klucze typu "ERROR" albo "FATAL". Przykład:

   ERROR:  relation "students" does not exist
   

2. Ostrzeżenia. Czasem możesz zobaczyć ostrzeżenia "WARNING". Nie są krytyczne, ale warto je przeczytać — mogą sygnalizować problemy:

   WARNING:  no privileges could be granted for table "grades"
   

3. Niezgodności danych. Sprawdź, czy wszystkie kluczowe obiekty się odtworzyły: tabele, indeksy, klucze obce.

Szybkie sprawdzanie z grep

Jeśli plik logów jest za długi (a bywa długi jak "Wojna i pokój"), możesz użyć grep, żeby szukać słów-kluczy:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Analiza błędów z logów

Zobaczmy prawdziwy przykład z loga:

ERROR:  constraint "fk_student_course" for relation "enrollments" does not exist
DETAIL:  Key (course_id)=(2) is not present in table "courses".

Co ten błąd nam mówi? To znaczy, że PostgreSQL próbuje odtworzyć wiersz w tabeli enrollments, ale nie istnieje odpowiedni course_id w tabeli courses.

Jak rozwiązać? Możliwe, że dane w tabeli courses były uszkodzone albo się nie odtworzyły. Musisz ręcznie dodać brakujące wiersze albo powtórzyć odtwarzanie.

Użycie sum kontrolnych do sprawdzania integralności

Jeśli chcesz mieć pewność, że plik backupu nie został uszkodzony przed lub po odtworzeniu, możesz użyć sum kontrolnych.

Suma kontrolna — to mała liczba reprezentująca dane w pliku. Jeśli plik zmieni się choćby o jeden bit, suma kontrolna też się zmieni. To pomaga wykryć, czy plik został uszkodzony.

Do stworzenia sumy kontrolnej możesz użyć narzędzia md5sum. Przykład komendy:

md5sum backup_file.dump

Wynik będzie wyglądał tak:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Porównanie sum kontrolnych

Jeśli wcześniej zapisałeś sumę kontrolną pliku, możesz ją porównać z aktualną:

md5sum -c checksum.md5

Plik checksum.md5 powinien zawierać linię z sumą kontrolną i nazwą pliku:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Jeśli suma kontrolna się zgadza, zobaczysz komunikat OK. Jeśli nie — plik jest uszkodzony.

Sprawdzanie danych na poziomie bazy

Sumy kontrolne i logi są spoko, ale jak sprawdzić, czy same dane są OK? Oto lista standardowych kroków:

1. Porównanie liczby wierszy

Porównaj liczbę wierszy w tabelach przed i po odtworzeniu. Na przykład:

-- Liczenie liczby wierszy w tabeli students
SELECT COUNT(*) FROM students;

Jeśli liczba wierszy się różni, odtwarzanie nie poszło w pełni.

2. Sprawdzanie integralności kluczy

Sprawdź powiązania między tabelami, żeby upewnić się, że wszystkie klucze obce działają:

-- Sprawdzanie studentów zapisanych na kursy
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Jeśli zapytanie zwraca wynik, to znaczy, że w tabeli enrollments są wiersze z brakującymi kursami.

3. Porównanie danych z oryginałem

Jeśli masz kopię danych (np. dump z innej bazy), możesz porównać wyniki zapytań:

-- Sprawdzanie danych z tabeli courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Prawdziwe przypadki odtwarzania

Przykład z życia: kiedyś admin bazy Bob postanowił odtworzyć dane z backupu po awarii serwera. Wykonał komendę:

pg_restore -U admin -d my_database my_backup.dump

Ale podczas analizy logów odtwarzanie zakończyło się błędem:

ERROR:  could not create file "base/16385/pg_internal.init": No space left on device

To znaczyło, że na dysku skończyło się miejsce. Po zwolnieniu miejsca i ponownym odtworzeniu danych odkrył też, że nie wszystkie tabele się odtworzyły. Na szczęście, dzięki wcześniej wygenerowanym sumom kontrolnym i ustawionej archiwizacji WAL Bob był w stanie w pełni odtworzyć bazę.

Podsumowanie sprawdzania integralności

Na koniec sprawdzania integralności danych po odtworzeniu zrób tak:

1. Sprawdź logi pod kątem błędów i ostrzeżeń.
2. Użyj sum kontrolnych, żeby upewnić się, że pliki nie są uszkodzone.
3. Porównaj dane bazy pod kątem liczby wierszy i integralności powiązań.
4. Jeśli coś poszło nie tak, przeanalizuj błędy i powtórz proces odtwarzania.

Teraz jesteś w pełni gotowy, żeby zrobić porządne sprawdzenie i mieć pewność, że dane zostały odtworzone dokładnie tak, jak się spodziewałeś. Bo najważniejsze w administrowaniu bazami danych — to pewność w swoim backupie!