pg_start_backupwykona punkt kontrolny, jak zauważa dezso. Ma to wpływ, ale twoja baza danych i tak dość regularnie wykonuje punkty kontrolne i musi to robić, aby działać, więc najwyraźniej nie stanowią dla ciebie problemu. Wczesny punkt kontrolny oznacza, że zgromadzono mniej danych, co oznacza, że w ogóle punkt kontrolny pg_start_backupbędzie miał mniejszy wpływ niż normalnie.
Trzeba się martwić o rsync lub równoważny pg_basebackupkrok. Odczytanie we / wy z tego nie będzie takie złe, ponieważ jest sekwencyjne, ale prawdopodobnie znacznie pogorszy wydajność we / wy bazy danych, a także będzie miał tendencję do wypychania gorących danych z pamięci podręcznej pamięci RAM na rzecz mniejszej -używane dane, powodując przeładowanie pamięci podręcznej, gdy bardziej potrzebne dane są następnie ponownie wczytywane.
Możesz użyć nicei, ioniceaby ograniczyć wpływ wejścia / wyjścia (ale nie wpływu pamięci podręcznej); wiąże się to jednak z pewnym kosztem. Tworzenie kopii zapasowej potrwa dłużej, a dopóki nie zakończysz tworzenia kopii zapasowej i nie uruchomisz pg_stop_backupsystemu, - jak rozumiem - kumuluje WAL, nie można go usunąć, kumuluje zadłużenie punktu kontrolnego dla DUŻEGO punktu kontrolnego na końcu przebiegu tworzenia kopii zapasowej oraz gromadzi tabelę i indeks wzdęcia, ponieważ nie można wyczyścić martwych rzędów. Tak naprawdę nie możesz sobie pozwolić na wieczność tworzenia kopii zapasowej, zwłaszcza jeśli masz bardzo wysokie tabele rezygnacji.
Ostatecznie trudno powiedzieć, czy można bezpiecznie używać kopii zapasowych w środowisku pg_start_backupi korzystać z nich pg_stop_backupna gorąco. Większość ludzi może, ale jeśli jesteś blisko krawędzi tego, co potrafi twój sprzęt, masz ścisłe wymagania dotyczące czasu, nie możesz sobie pozwolić na ryzyko przeciągnięcia i masz bardzo wysokie tabele rezygnacji, a także bardzo duże stoły, może to być kłopotliwe .
Niestety, musisz to przetestować i zobaczyć.
Jeśli możesz, warto wydać CHECKPOINTatomową migawkę woluminu, w którym znajduje się baza danych, zamiast tego przy użyciu LVM, narzędzi SAN, EBS lub czegokolwiek, na czym się znajdujesz. Jeśli możesz to zrobić, możesz skopiować migawkę w dowolnym momencie. To podejście nie jest odpowiednie do wykonywania bazowej kopii zapasowej dla PITR / ciepłego trybu gotowości / gorącego trybu gotowości, ale doskonale nadaje się do statycznej kopii zapasowej i ma znacznie mniejszy wpływ na system. Możesz to zrobić tylko wtedy, gdy migawki są atomowe, a cała baza danych, w tym WAL, znajduje się na jednym woluminie.
Jedną z możliwości, których jeszcze nie zbadałem, jest połączenie tych dwóch podejść. Przyszło mi do głowy, że można ( niepotwierdzone i być może złe i niebezpieczne , jeszcze nie wiem):
pg_start_backup- Wyzwalanie migawek wszystkich obszarów tabel, głównego katalogu danych i woluminu xlog
pg_stop_backup- Skopiuj WAL do ostatecznego archiwum z
pg_stop_backup
- Skopiuj dane z migawkowych woluminów
Zasadniczo chodzi o to, aby skrócić czas, przez jaki DB musi opóźniać swoje punkty kontrolne, biorąc pod uwagę każdy wolumin, który można skopiować w wolnym czasie.