Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
PostgreSQL
Replika przestała się synchronizować - jak wznowić replikację
pg_basebackup.Replikacja fizyczna strumieniowa w trybie hot-standby to podstawowy sposób utrzymania gorącej kopii bazy. Bywa jednak, że replika zatrzymuje się albo dryfuje coraz dalej od primary. Pokażemy, jak ustalić, dlaczego przestała się synchronizować, i jak wznowić replikację bez utraty danych.
Na replice rośnie opóźnienie: dane, które widzisz, są coraz starsze względem primary. W skrajnym przypadku proces WAL receiver na replice znika i połączenie replikacyjne nie odbudowuje się. W logu repliki pojawia się komunikat, że żądany segment WAL nie jest już dostępny na serwerze nadrzędnym, albo że odtwarzanie zostało przerwane z powodu konfliktu z zapytaniami. Na primary widok pg_stat_replication może w ogóle nie pokazywać tej repliki, co oznacza, że strumień jest zerwany. Aplikacja czytająca z repliki nagle serwuje nieaktualne dane, a próba przełączenia awaryjnego okazuje się ryzykowna, bo standby jest daleko w tyle.
Replikacja strumieniowa polega na tym, że replika pobiera z primary kolejne pliki WAL i je odtwarza. Jeśli replika na chwilę odpadnie (sieć, restart, przeciążenie) i wróci później, niż primary trzyma stare WAL-e, to potrzebnych segmentów już nie ma i strumienia nie da się wznowić. Bez slotu replikacyjnego primary nie wie, że ma je zachować, więc czyści je zgodnie z wal_keep_size i checkpointami. Drugi typowy powód to konflikty odtwarzania: długie zapytania na replice blokują nakładanie zmian, a parametr max_standby_streaming_delay decyduje, czy PostgreSQL poczeka, czy przerwie zapytanie. Zdarza się też zwykłe przeciążenie repliki, która nie nadąża odtwarzać WAL tak szybko, jak primary go generuje, co daje rosnące opóźnienie mimo poprawnego połączenia.
pg_stat_replication (czy replika jest widoczna i jaki ma stan) oraz pg_replication_slots, jeśli używasz slotów. Na replice sprawdź opóźnienie funkcjami czasu odtwarzania.primary_slot_name). Slot każe primary zachować WAL, dopóki replika ich nie potwierdzi.restore_command), żeby domknęła lukę z kopii archiwalnej.max_standby_streaming_delay lub włączenie hot_standby_feedback, żeby primary nie usuwał wersji wierszy potrzebnych długim zapytaniom na replice.pg_basebackup z primary (najlepiej z utworzeniem slotu), ustaw standby.signal i parametry połączenia, po czym wystartuj.Na primary w widoku pg_stat_replication replika powinna być widoczna ze stanem streaming, a różnice między pozycjami wysłania, zapisu i odtworzenia WAL powinny być małe i stabilne. Na replice policz opóźnienie funkcją pg_last_xact_replay_timestamp() i porównaj z czasem bieżącym - powinno spadać do sekund. Wykonaj też prosty test end-to-end: zapisz znacznik na primary, a po chwili odczytaj go z repliki. Jeśli znacznik dociera szybko i opóźnienie się nie kumuluje, replikacja działa poprawnie.
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
Komentarze (0)
Brak komentarzy...