Częste problemy z replikacją i jak je diagnozować

PostgreSQL

Częste problemy z replikacją i jak je diagnozować

W skrócie

Replikacja PostgreSQL rzadko psuje się spektakularnie - częściej dryfuje, zwalnia albo cicho się rozłącza. Klucz to szybka diagnoza: te same widoki i logi odpowiadają na większość pytań. Zebraliśmy najczęstsze problemy z replikacją i pokazujemy, jak metodycznie namierzyć źródło każdego z nich.

Jak to wygląda w praktyce

Objawy bywają mylące. Replika zwraca nieaktualne dane, choć połączenie wygląda na żywe. Opóźnienie replikacji skacze w górę pod obciążeniem i nie chce zejść. Na standby zapytania są nagle przerywane komunikatem o konflikcie z odtwarzaniem. Dysk na primary puchnie bez wyraźnego powodu, bo slot replikacyjny trzyma WAL. Po restarcie sieci replika nie odbudowuje strumienia i log powtarza, że brakuje segmentu WAL. W przypadku replikacji logicznej subskrypcja staje na błędnej transakcji i nie rusza. To wszystko różne twarze kilku typowych przyczyn, a bez uporządkowanej diagnozy łatwo gonić nie ten trop i marnować godziny.

Dlaczego tak się dzieje

Replikacja to łańcuch: primary generuje WAL, dostarcza go przez sieć, replika odbiera i odtwarza. Problem może siedzieć w każdym ogniwie. Brak WAL na primary (bo został usunięty, zanim replika go pobrała) zrywa strumień. Za wolna replika albo słabszy sprzęt standby powoduje rosnące opóźnienie mimo poprawnego połączenia. Konflikty odtwarzania biorą się z tego, że długie zapytania na standby blokują nakładanie zmian, a parametry max_standby_streaming_delay i hot_standby_feedback decydują, kto ustąpi. Zapchany dysk to zwykle nieaktywny lub osierocony slot, który trzyma WAL w nieskończoność. Zrywy sieci albo agresywne timeouty (wal_receiver_timeout) przerywają połączenie replikacyjne. W replikacji logicznej dochodzą konflikty danych i brak jednoznacznej tożsamości wierszy. Każda z tych przyczyn zostawia charakterystyczny ślad w konkretnym widoku lub w logu.

Jak to rozwiązać krok po kroku

1. Zacznij od primary: sprawdź pg_stat_replication. Jeśli replika jest widoczna i w stanie streaming, połączenie żyje; jeśli jej nie ma, strumień jest zerwany i idź w stronę WAL i sieci.
2. Zmierz opóźnienie. Na standby użyj pg_last_xact_replay_timestamp() i porównaj z czasem bieżącym, a różnice pozycji wysłania, zapisu i odtworzenia WAL odczytaj z pg_stat_replication. Rosnące odtwarzanie przy nadążającym odbiorze wskazuje na wolną replikę.
3. Sprawdź sloty w pg_replication_slots: czy slot jest aktywny i ile WAL zatrzymuje. Nieaktywny, rosnący slot to najczęstsza przyczyna zapchanego dysku - usuń osierocony slot.
4. Zajrzyj do logów po obu stronach. Komunikat o brakującym segmencie WAL kieruje na sloty i archiwum; komunikat o konflikcie odtwarzania kieruje na parametry opóźnienia standby.
5. Przy konfliktach odtwarzania rozważ zwiększenie max_standby_streaming_delay albo włączenie hot_standby_feedback, żeby pogodzić długie zapytania na standby z nakładaniem zmian.
6. Przy zrywach sieci sprawdź stabilność łącza i wartości wal_receiver_timeout oraz wal_sender_timeout; zbyt niskie potrafią przerywać zdrowe, ale wolniejsze połączenia.
7. Dla replikacji logicznej dołóż pg_stat_subscription na subskrybencie i sprawdź, czy postęp LSN rośnie; jeśli stoi, szukaj konfliktu danych w logu subskrybenta.

Jak sprawdzić, że zadziałało

Po naprawie potwierdź zdrowie łańcucha w tych samych miejscach, w których szukałeś problemu. W pg_stat_replication replika powinna być w stanie streaming z małymi, stabilnymi różnicami pozycji WAL. Opóźnienie z pg_last_xact_replay_timestamp() powinno utrzymywać się na poziomie sekund i nie kumulować pod obciążeniem. Slot w pg_replication_slots ma być aktywny, a zatrzymany WAL mały. Zrób test end-to-end: zapisz znacznik na primary i odczytaj go z repliki po chwili. Dla replikacji logicznej sprawdź, że postęp w pg_stat_subscription rośnie i testowy wiersz dociera do subskrybenta. Gdy wszystkie te sygnały są zielone, replikacja jest zdrowa.

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