Sloty replikacji - kiedy ich używać i jak nie zapełnić dysku

PostgreSQL

Sloty replikacji - kiedy ich używać i jak nie zapełnić dysku

W skrócie

Sloty replikacji rozwiązują odwieczny problem: primary usuwa pliki WAL, zanim replika zdąży je pobrać, i strumień się rwie. Slot gwarantuje, że potrzebne segmenty poczekają. Ta sama cecha jest jednak pułapką - nieużywany slot potrafi zapełnić dysk i zatrzymać całą bazę. Pokażemy, kiedy sloty włączać i jak nad nimi zapanować.

Jak to wygląda w praktyce

Bez slotów replika po dłuższym rozłączeniu wraca i widzi, że brakuje segmentów WAL, których primary już nie ma. Strumienia nie da się wznowić, trzeba przebudowywać standby. To pierwszy objaw, który skłania do włączenia slotów. Drugi objaw pojawia się później i jest groźniejszy: katalog WAL na primary (podkatalog pg_wal) puchnie w nieskończoność, aż dysk się zapełnia i baza przestaje przyjmować zapisy. Zaglądasz do pg_replication_slots i widzisz slot, który jest nieaktywny albo należy do repliki, której już dawno nie ma, a mimo to primary trzyma dla niego gigabajty WAL. Klasyczny przypadek: skasowano replikę, ale zapomniano usunąć jej slot.

Dlaczego tak się dzieje

PostgreSQL normalnie usuwa stare pliki WAL po checkpointach, kierując się parametrami takimi jak wal_keep_size. Slot replikacyjny łamie tę zasadę celowo: primary zapamiętuje, do którego miejsca w WAL dana replika potwierdziła odbiór, i nie usuwa niczego nowszego. Dzięki temu replika zawsze znajdzie potrzebne segmenty, nawet po długiej przerwie. Problem w tym, że jeśli replika przestaje potwierdzać (jest wyłączona, zerwana albo w ogóle już nie istnieje), punkt potwierdzenia slotu stoi w miejscu, a WAL narasta bez końca. To samo dotyczy slotów logicznych, gdzie dodatkowo blokowane jest czyszczenie wersji wierszy. Zabezpieczeniem jest parametr max_slot_wal_keep_size, który wyznacza górny limit tego, ile WAL slot może zatrzymać - po jego przekroczeniu slot zostaje unieważniony, żeby ratować dysk kosztem tej jednej repliki.

Jak to rozwiązać krok po kroku

1. Zdecyduj, czy slot jest potrzebny. Dla stałej repliki, która musi przetrwać przerwy sieciowe, slot jest właściwym wyborem. Dla jednorazowego pg_basebackup zwykle wystarczy slot tymczasowy.
2. Utwórz slot fizyczny funkcją pg_create_physical_replication_slot('nazwa') i wskaż go replice parametrem primary_slot_name, żeby faktycznie z niego korzystała.
3. Ustaw bezpiecznik na primary: nadaj max_slot_wal_keep_size rozsądny limit (na tyle duży, by przetrwać typowe przerwy, ale mniejszy niż wolne miejsce na dysku), żeby awaria repliki nie zatrzymała całej bazy.
4. Włącz monitoring zaległości slotów: obserwuj w pg_replication_slots kolumny stanu oraz rozmiar zatrzymanego WAL, a także flagę mówiącą, czy slot jest aktywny.
5. Ustaw alarm na nieaktywny slot i na przekroczenie progu zatrzymanego WAL, żeby dowiedzieć się o problemie, zanim dysk się zapełni.
6. Gdy replika znika na stałe, usuń jej slot funkcją pg_drop_replication_slot('nazwa'). To najczęstsza przyczyna zapchanego dysku i najprostsza naprawa.
7. Przy slotach logicznych dodatkowo pilnuj, by subskrybent nadążał, bo zaległy slot logiczny blokuje też czyszczenie martwych wersji wierszy i puchnie szybciej.

Jak sprawdzić, że zadziałało

Podstawowy widok to pg_replication_slots: dla zdrowej repliki slot powinien być aktywny, a ilość zatrzymanego WAL - mała i stabilna. Sprawdź, że zajętość katalogu pg_wal nie rośnie bez końca po wznowieniu repliki. Zrób test odporności: zatrzymaj replikę na chwilę, zobacz, że primary zaczyna trzymać WAL dla slotu, a po ponownym starcie replika domyka lukę i zatrzymany WAL zostaje zwolniony. Jeśli po przywróceniu repliki rozmiar zatrzymanego WAL wraca do zera, a przy zniknięciu repliki bezpiecznik max_slot_wal_keep_size nie pozwala mu urosnąć ponad limit, sloty są skonfigurowane bezpiecznie.

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