Używasz pg_dump na gorącym serwerze rezerwowym?

Oświadczenie: Wprawdzie jeszcze tego nie próbowałem, ale nie jestem pewien, czy wiedziałbym, czy to nie działałoby poprawnie, więc chciałem zapytać.

Chciałbym uruchomić nocne zadanie tworzenia kopii zapasowej (przez pg_dumpall) z serwera w trybie gotowości na gorąco z uruchomioną replikacją przesyłania strumieniowego, aby uniknąć obciążenia głównego. Widziałem tylko wzmiankę o niektórych gotchach, na które wpadli ludzie, np. Tu i tutaj , ale bardzo niewiele wskazówek. Jest w porządku, jeśli kopia zapasowa jest nieco opóźniona w stosunku do podstawowej, o ile jest spójna (która powinna być).

Moje pytania to:

1. Czy naprawdę chcę to zrobić, czy należy wykonać kopię zapasową na serwerze podstawowym? Czemu?

2. Kiedy wykonuję zrzut w trybie gotowości, jakich ustawień potrzebuję i jakich procedur powinienem użyć, aby zrobić to poprawnie? np. czy muszę zatrzymać replikację na czas tworzenia kopii zapasowej?

AFAIK, praca pg_dumpw trybie gotowości na gorąco jest jedną z głównych rzeczy, do których przydają się standby. Jest całkowicie bezpieczny, choć nie jest całkowicie niezawodny - zrzuty mogą się nie powieść, jeśli tryb gotowości przerwie transakcję, gdy będzie zbyt daleko w tyle za urządzeniem głównym.

Jedyne, co naprawdę musisz obejrzeć, to upewnić się, że tryb gotowości jest aktualny i nadąża. Jeśli tryb gotowości utracił połączenie z urządzeniem głównym i pozostawał zbyt daleko w tyle, nie chcesz wesoło tworzyć kopii zapasowej przez trzy tygodnie przestarzałej gotowości.

Podczas tworzenia kopii zapasowej będziesz musiał pozostawić tryb gotowości dość daleko w tyle za urządzeniem głównym, ponieważ w przeciwnym razie będzie trzeba anulować pg_dumptransakcję, aby kontynuować odtwarzanie WAL. Zobacz dokumentację na temat trybu gotowości w trybie gotowości , w szczególności sekcję „obsługa konfliktów zapytań” max_standby_archive_delayoraz max_standby_streaming_delayparametry i .

Zauważ, że master musi być gotowy do przechowywania wystarczającej ilości archiwów WAL, aby umożliwić niewolnikowi ponowne nadrobienie zaległości.

1. W trybie gotowości wykonujemy kopie zapasowe, wszystko jest w porządku.
2. Aby uniknąć konfliktu anulowanych instrukcji podczas tworzenia kopii zapasowej w systemie rezerwowym, należy wstrzymać replikację w trybie gotowości za pomocą SELECT pg_xlog_replay_pause();, a następnie uruchomić kopię zapasową, gdy zakończy się, SELECT pg_xlog_replay_resume();aby wznowić replikację. Należy pamiętać, że uruchomienie powyższych poleceń spowoduje opóźnienie odzyskiwania na urządzeniu podrzędnym, które może być dość duże, w zależności od wielkości bazy danych. Weź również pod uwagę przestrzeń, jaką zajmą segmenty WAL, ponieważ nie będą one odtwarzane na niewolniku podczas pauzy.

Można znaleźć kilka innych przydatnych funkcji administractive w dokumentacji . Na przykład, należy sprawdzić, czy serwer jest rzeczywiście w odzyskiwaniu przed zatrzymując go: SELECT pg_is_in_recovery().

Jeśli wstrzymasz replikację podczas tworzenia kopii zapasowej (jest to dobry pomysł dla zachowania integralności i spójności), możesz edytować niektóre wiersze w głównym postgresql:

Ile czasu zwykle opóźnia tworzenie kopii zapasowej. Upewnij się, że węzeł główny zachowuje całe pliki x_log niezbędne do wznowienia replikacji. Możesz to zrobić w edycji postgresql.conf

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

Jeśli nie zmodyfikujesz tego, a proces tworzenia kopii zapasowej jest zbyt długi, prawdopodobnie węzeł główny usuwa pliki xlog przed wysłaniem ich do urządzenia podrzędnego.