Blog JSystems - uwalniamy wiedzę!

Szukaj


Z tego artykułu dowiesz się:

  • jak zatrzymywać i wznawiać replikację,
  • jak konfigurować opóźnienie w replikacji – np. gdy chcemy mieć replikę serwera zawsze w stanie sprzed godziny.




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ą.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...