PostgreSQL - Opóźniona replikacja fizyczna

Konfiguracja opóźnionej replikacji sprowadza się do ustawienia parametru recovery_min_apply_delay przyjmującego wartości w milisekundach. Jest to opcja dedykowana dla replikacji strumieniowej, ale replikacja WAL-shipping również się do niej stosuje. Mechanizm opóźnionego odtwarzania opiera się na znaczniku czasowym commita z pliku WAL oraz zegarze systemowym na replice. Dlatego czas odtworzenia pliku WAL po skopiowaniu może być w pewnych przypadkach mniejszy lub większy niż skonfigurowane opóźnienie.

Jej głównym zastosowaniem jest możliwość szybkiego odzyskania danych, głównie w przypadku wystąpienia błędu ludzkiego, tzw. PBKAC (Problem Between Keyboard And Chair). Przykładowo, posiadając replikę opóźnioną o 1 godzinę, po omyłkowym usunięciu kilku tysięcy wierszy, możemy je bardzo łatwo odzyskać z opóźnionej repliki- o ile zdążymy zauważyć ten błąd w ciągu godziny :) Wystarczy zatrzymać replikację i skopiować utracone dane lub zatrzymać klaster, skonfigurować parametry odzyskiwania na odpowiedni moment w czasie, odzyskać usunięte przypadkowo dane i skopiować z powrotem do instancji głównej albo w ostateczności po prostu otworzyć bazę do zapisu i korzystać z niej jako klastra primary.

Korzystając z opóźnionej replikacji, warto pamiętać, że parametry takie jak hot_standby_feedback czy synchronous_commit również działają dla opóźnionej instancji, dlatego trzeba z nich korzystać bardzo uważnie. Przykładowo, instancja primary będzie czekała na informację zwrotną z opóźnionej repliki, kiedy może wyczyścić tabele za pomocą autovacuum, co - może opóźnić vacuum o recovery_min_apply_delay i prowadzić do znacznego bloatu w bazie danych. Korzystanie z synchronous_commit = remote_apply sprawi, że primary będzie czekał, aż transakcja będzie mogła zostać zacommitowana na opóźnionej replice, co odłoży w czasie wszystkie commity na primary o skonfigurowany recovery_min_apply_delay.

Zatrzymywanie i wznawianie odtwarzania replikacji

[host 2: serwer replika]

Odtwarzanie zmian w replikacji strumieniowej i wal-shipping możemy w dowolnym momencie zatrzymać i wznowić. Domyślnie tylko superuser (użytkownik postgres w klastrze) ma uprawnienia na wykonanie tych funkcji, ale możemy je nadać dowolnemu użytkownikowi.
Przykładowo:

postgres=# grant execute on function pg_wal_replay_pause() to jakis_user;

Zatrzymać replikację możemy za pomocą polecenia:

postgres=# select pg_wal_replay_pause();

Powyższa funkcja wykona się w ułamku sekundy, nie oznacza to jednak, że odtwarzanie się zakończyło. Postgres przestanie odtwarzać nowe zmiany, ale zakończy odtwarzanie wszystkich rozpoczętych transakcji.

Po skończeniu odtwarzania w logu zobaczymy informację:

LOG: - recovery has paused

Aby sprawdzić, czy replikacja została już całkowicie zatrzymana z - poziomu postgresa, możemy wykonać funkcje pg_is_wal_replay_paused() oraz pg_get_wal_replay_pause_state(). Pierwsza zwraca t lub f, co oznacza true i false. Jeżeli funkcja zwraca t, replikacja jest zatrzymana, jeżeli nie- zwraca f. Druga funkcja służy do dokładniejszego sprawdzania, czy proces odtwarzania zmian został zatrzymany. Możliwe wyniki to "not paused", "pause requested" jeżeli - wywołana została funkcja pg_wal_replay_pause(), ale postgres musi jeszcze dokończyć odtwarzanie zaczętych transakcji, oraz "paused".

postgres=# select pg_is_wal_replay_paused();
 pg_is_wal_replay_paused
-------------------------
 t
(1 row)

postgres=# select pg_get_wal_replay_pause_state();
 pg_get_wal_replay_pause_state
-------------------------------
 paused
(1 row)

Co ważne, zatrzymanie odtwarzania zmian nie powoduje, że stracimy jakieś transakcje. Wszystkie zmiany dokonane w czasie, kiedy replikacja była zatrzymana, będą odtworzone po wznowieniu, jeżeli korzystamy ze slotów replikacyjnych, slot będzie przetrzymywał pliki WAL do momentu wznowienia odtwarzania zmian. Jeżeli nie i pliki WAL zostaną już usunięte z instancji primary, postgres spróbuje je odzyskać z archiwum, za pomocą restore_command, i odtworzyć.

Wznawianie odtwarzania zmian możemy wykonać za pomocą funkcji pg_wal_replay_resume();

postgres=# select pg_wal_replay_resume();

Informacja o możliwym wznowieniu replikacji znajduje się też w logu postgresa.

LOG: - recovery has paused
HINT: - Execute pg_wal_replay_resume() to continue.

Zatrzymywanie odtwarzanie przydatne jest w sytuacjach, kiedy jak te opisywane przy opóźnionej replikacji, lub kiedy wykonujemy duże zmiany na instancji primary, możemy zatrzymać odtwarzanie na jednej z replik i w przypadku niepowodzenia, użyć jej jako szybki powrót do stanu przed wykonaną zmianą.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5