Nieużywany slot replikacji trzyma WAL - jak to wykryć

PostgreSQL

Nieużywany slot replikacji trzyma WAL - jak to wykryć

W skrócie

Sloty replikacji to świetny mechanizm, który gwarantuje, że replika nie zgubi danych - ale porzucony slot potrafi zapchać dysk primary i doprowadzić do zatrzymania bazy. Pokażemy Ci, jak go namierzyć i unieszkodliwić.

Jak to wygląda w praktyce

Monitoring krzyczy, że partycja z pg_wal jest niemal pełna. Sprawdzasz checkpointy - działają, max_wal_size jest rozsądny, a mimo to liczba plików WAL rośnie z godziny na godzinę i nie spada po checkpoincie. To klasyczny objaw slotu replikacji, który blokuje usuwanie starych segmentów. Często zdarza się to po tym, jak replika została wyłączona lub przepięta, a slot na primary został "na wszelki wypadek" i nikt go nie posprzątał. W skrajnym przypadku dysk zapełnia się do końca i serwer przestaje przyjmować zapisy - dlatego warto wychwycić to wcześnie.

Dlaczego tak się dzieje

Slot replikacji to obietnica, którą primary składa odbiorcy WAL (replice fizycznej albo subskrypcji logicznej): "nie usunę segmentów WAL, których jeszcze nie potwierdziłeś". Dopóki slot istnieje, primary zachowuje wszystkie pliki WAL od pozycji restart_lsn tego slotu - niezależnie od checkpointów i max_wal_size. Jeśli odbiorca się rozłączy, slot pozostaje, jego restart_lsn zamarza, a różnica między bieżącą pozycją WAL a tym LSN rośnie w nieskończoność. To celowe zachowanie: slot ma chronić przed utratą danych. Problem pojawia się dopiero, gdy slot nie ma już żadnego czynnego odbiorcy - wtedy trzyma WAL bez powodu i zapycha dysk.

Jak to rozwiązać krok po kroku

1. Wylistuj wszystkie sloty i sprawdź, które są nieaktywne oraz ile WAL trzymają: SELECT slot_name, slot_type, active, restart_lsn, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS zalegly_wal FROM pg_replication_slots ORDER BY 5 DESC;
2. Zwróć uwagę na kolumnę active. Wartość false oznacza, że w tej chwili nikt nie jest podłączony do slotu. Duży zalegly_wal przy active = false to nasz podejrzany.
3. Potwierdź, że slot jest naprawdę zbędny. Sprawdź w kolumnie wal_status, czy nie jest to slot potrzebnej repliki, która chwilowo odpadła. Nigdy nie usuwaj slotu działającej repliki - stracisz z nią synchronizację.
4. Jeśli slot jest osierocony, usuń go: SELECT pg_drop_replication_slot('nazwa_slotu');. Nie da się skasować slotu aktywnego (z podłączonym odbiorcą) - to bezpiecznik chroniący przed pomyłką.
5. Ustaw twardy limit, ile WAL slot może maksymalnie zatrzymać: ALTER SYSTEM SET max_slot_wal_keep_size = '10GB'; i przeładuj konfigurację przez SELECT pg_reload_conf();. Powyżej tego limitu serwer poświęci slot, zamiast zapchać dysk (slot przejdzie w stan lost).
6. Rozważ monitoring: alert, gdy dowolny slot z active = false przekroczy próg zaległego WAL. To pozwoli reagować, zanim dysk się zapełni.

Jak sprawdzić, że zadziałało

Po usunięciu osieroconego slotu najbliższy checkpoint zwolni zbędne segmenty WAL, a liczba plików w pg_wal zacznie spadać - to najlepszy dowód. Wykonaj ponownie zapytanie do pg_replication_slots i upewnij się, że podejrzanego slotu już nie ma na liście albo że jego zalegly_wal przestał rosnąć. Sprawdź wolne miejsce na partycji z pg_wal po następnym checkpoincie - powinno wyraźnie wzrosnąć. Jeżeli WAL nadal narasta, wróć do listy slotów: prawdopodobnie jest jeszcze jeden nieaktywny slot albo działający slot, którego odbiorca nie nadąża z konsumpcją i realnie potrzebuje uwagi.

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