Jak poprawnie zatrzymać i zrestartować klaster PostgreSQL

PostgreSQL

Jak poprawnie zatrzymać i zrestartować klaster PostgreSQL

W skrócie

Zatrzymanie i restart klastra PostgreSQL wygląda na trywialną operację, dopóki nie trafisz na serwer, który nie chce się wyłączyć albo wisi kilkanaście minut z otwartymi połączeniami. Pokażemy Ci, czym różnią się tryby zatrzymania, kiedy wystarczy zwykłe przeładowanie konfiguracji i jak potwierdzić, że klaster faktycznie stanął albo wstał. Temat dotyczy każdego, kto administruje bazą na własnym serwerze i musi ją bezpiecznie zrestartować.

Jak to wygląda w praktyce

Wydajesz polecenie zatrzymania serwera i konsola po prostu wisi. Nic się nie dzieje, a Ty nie wiesz, czy PostgreSQL kończy pracę, czy się zawiesił. W innym scenariuszu serwer gaśnie natychmiast, ale przy ponownym starcie widzisz w logu informację o odzyskiwaniu po awarii, choć przecież wyłączyłeś go ręcznie. Bywa też odwrotnie: potrzebujesz tylko zmienić jeden parametr, a robisz pełny restart i niepotrzebnie zrywasz wszystkim otwarte sesje. Wspólny mianownik jest jeden: nie wiadomo, co dokładnie robi polecenie, którego użyłeś, i w jakim stanie zostawia bazę.

Dlaczego tak się dzieje

PostgreSQL nie ma jednego sposobu na zatrzymanie. Narzędzie pg_ctl przyjmuje parametr trybu i to on decyduje o wszystkim. Tryb smart czeka, aż wszyscy klienci sami się rozłączą, więc jeśli ktoś trzyma otwarte połączenie, serwer będzie czekał w nieskończoność i wygląda to jak zawieszenie. Tryb fast, który jest domyślny w nowszych wersjach, rozłącza klientów natychmiast, wycofuje niezatwierdzone transakcje i wykonuje porządne zamknięcie z zapisem danych na dysk. Tryb immediate ubija procesy bez zamknięcia, dlatego przy następnym starcie baza musi przejść odzyskiwanie z dziennika WAL, dokładnie tak jak po zaniku zasilania. Do tego dochodzi mylenie dwóch operacji: restart faktycznie zatrzymuje i uruchamia serwer, natomiast reload jedynie każe procesowi ponownie wczytać pliki konfiguracyjne bez przerywania pracy. Część parametrów da się zmienić właśnie przez reload, a tylko część wymaga pełnego restartu.

Jak to rozwiązać krok po kroku

1. Zdecyduj, czy naprawdę potrzebujesz restartu. Jeśli zmieniasz tylko parametr w pliku konfiguracyjnym, sprawdź, czy nie wystarczy przeładowanie. Do tego służy polecenie pg_ctl reload albo z poziomu bazy funkcja pg_reload_conf().
2. Do planowego wyłączenia używaj trybu fast: pg_ctl stop -m fast. Rozłączy on klientów i wycofa ich niezatwierdzone transakcje, ale zamknie bazę porządnie, więc następny start nie będzie wymagał odzyskiwania.
3. Jeśli chcesz poczekać, aż użytkownicy sami zakończą pracę, wybierz tryb smart: pg_ctl stop -m smart. Pamiętaj, że przy stale otwartych połączeniach będzie czekać bardzo długo.
4. Tryb immediate (pg_ctl stop -m immediate) trzymaj na wypadek, gdy serwer nie reaguje na nic innego. Świadomie godzisz się wtedy na odzyskiwanie przy następnym starcie.
5. Do restartu użyj jednego polecenia: pg_ctl restart -m fast. Połączy ono zatrzymanie w trybie fast z ponownym uruchomieniem.
6. Jeżeli bazą zarządza systemd, rób to przez usługę, na przykład poleceniem systemctl restart z nazwą jednostki, bo wtedy menedżer usług zna właściwą ścieżkę do katalogu danych i nie wejdziesz w konflikt z automatycznym startem.
7. Za każdym razem poczekaj na komunikat potwierdzający i dopiero po nim uznaj operację za zakończoną. Nie przerywaj polecenia w połowie.

Jak sprawdzić, że zadziałało

Stan serwera potwierdzisz poleceniem pg_ctl status, które powie Ci, czy proces działa i z jakim identyfikatorem. Po starcie zajrzyj do dziennika serwera i poszukaj wpisu o gotowości do przyjmowania połączeń. Jeśli robiłeś tylko reload, w logu zobaczysz linię o ponownym wczytaniu konfiguracji, a nie o starcie od zera. Praktyczny sprawdzian po zmianie parametru to zalogować się przez psql i wykonać SHOW z nazwą tego parametru, żeby zobaczyć nową wartość na żywo. Gdy start faktycznie wymagał odzyskiwania, log wprost napisze o odtwarzaniu z dziennika, i to jest sygnał, że poprzednie zatrzymanie nie było czyste.

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