PostgreSQL nie wstaje po nagłym wyłączeniu serwera - recovery

PostgreSQL

PostgreSQL nie wstaje po nagłym wyłączeniu serwera - recovery

W skrócie

Po zaniku prądu albo twardym resecie serwera PostgreSQL potrafi przez chwilę nie odpowiadać, a w logu widać komunikaty o odzyskiwaniu. To moment, w którym łatwo o panikę i o najgorszą możliwą reakcję, czyli kasowanie plików bazy w nadziei, że pomoże. Wyjaśnimy Ci, dlaczego baza tak się zachowuje, kiedy to całkowicie normalne, a kiedy faktycznie masz problem, i jak bezpiecznie doprowadzić klaster z powrotem do pracy. Temat jest dla każdego, kto administruje bazą po niekontrolowanym wyłączeniu.

Jak to wygląda w praktyce

Serwer wraca do życia po awarii zasilania, a aplikacja zgłasza, że nie może się połączyć z bazą. Próba logowania przez psql kończy się informacją, że system startuje. W dzienniku serwera widzisz wpisy mówiące, że baza wykonuje odzyskiwanie, przetwarza dziennik od pewnego punktu i jeszcze nie jest gotowa na przyjmowanie połączeń. Czasem trwa to sekundy, a czasem znacznie dłużej i wygląda, jakby nic się nie działo. W skrajnym przypadku start w ogóle się nie udaje, a log mówi o pliku pid, o zajętym katalogu danych albo o uszkodzeniu, i wtedy sytuacja jest poważniejsza.

Dlaczego tak się dzieje

PostgreSQL zapisuje każdą zmianę najpierw do dziennika z wyprzedzeniem, czyli WAL, a dopiero potem, w tle, przenosi ją do właściwych plików danych. Dzięki temu po nagłym zatrzymaniu baza wie, które zmiany zostały potwierdzone, ale mogły jeszcze nie trafić na dysk w plikach danych. Przy starcie po niekontrolowanym wyłączeniu serwer wykrywa, że poprzednie zamknięcie nie było czyste, i uruchamia odzyskiwanie awaryjne. Odtwarza z dziennika wszystkie potwierdzone zmiany od ostatniego punktu kontrolnego i wycofuje transakcje, które nie zdążyły się zatwierdzić. To właśnie ten mechanizm chroni Twoje dane i sprawia, że po awarii baza wstaje spójna. Dłuższe odzyskiwanie oznacza po prostu, że od ostatniego punktu kontrolnego uzbierało się dużo zmian do odtworzenia. Osobny przypadek to start blokowany przez plik pid pozostały po ubitym procesie albo faktyczne uszkodzenie nośnika, i to trzeba odróżnić od zwykłego odzyskiwania.

Jak to rozwiązać krok po kroku

1. Zajrzyj najpierw do dziennika serwera. Jeśli widzisz wpisy o trwającym odzyskiwaniu i odtwarzaniu dziennika, to znaczy, że baza pracuje poprawnie. Nie przerywaj jej.
2. Daj odzyskiwaniu dokończyć. Nie restartuj serwera w kółko, bo za każdym razem proces zaczyna się od nowa i tylko wydłużasz oczekiwanie. Poczekaj na wpis o gotowości do przyjmowania połączeń.
3. Jeżeli start się nie udaje z powodu istniejącego pliku pid, a masz pewność, że żaden proces serwera nie działa, dopiero wtedy usuń plik postmaster.pid z katalogu danych i spróbuj ponownie. Nigdy nie rób tego przy działającym serwerze.
4. Sprawdź, czy proces PostgreSQL rzeczywiście nie działa w tle, zanim uznasz katalog danych za wolny. Konflikt dwóch procesów na tym samym katalogu grozi uszkodzeniem.
5. Gdy log mówi o uszkodzeniu plików albo o braku dostępu do dysku, zatrzymaj się i nie próbuj naprawiać na ślepo. Zabezpiecz kopię katalogu danych i dopiero na kopii prowadź dalsze działania.
6. Do rutynowych zamknięć na przyszłość zawsze używaj kontrolowanego zatrzymania w trybie fast zamiast wyłączania serwera z gniazdka, bo wtedy baza w ogóle nie musi przechodzić odzyskiwania.

Jak sprawdzić, że zadziałało

Odzyskiwanie zakończyło się pomyślnie, jeśli w dzienniku serwera znajdziesz linię o gotowości do przyjmowania połączeń, a próba logowania przez psql się udaje. Wykonaj proste zapytanie, na przykład SELECT 1;, żeby potwierdzić, że baza odpowiada. Sprawdź też w logu, że po komunikacie o odzyskiwaniu nie ma dalszych błędów. Jeśli aplikacja znów się łączy i widzisz swoje dane sprzed awarii, mechanizm dziennika zadziałał tak, jak powinien. Gdyby po odzyskiwaniu w logu wciąż powtarzały się błędy o dostępie do plików, to sygnał, że problem leży w nośniku, a nie w samym PostgreSQL.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5