Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
PostgreSQL
Jak zrobić gorący backup fizyczny (pg_basebackup)
pg_basebackup robi gorący backup fizyczny - pełny obraz całego klastra pobrany po protokole replikacji, bez zatrzymywania bazy. To fundament pod repliki i pod odtwarzanie do punktu w czasie. Pokazujemy, jak go poprawnie wykonać i jak z niego wystartować działający serwer.
To zadanie planowe: budujesz replikę, przygotowujesz bazę do PITR albo chcesz szybkiego, pełnego odtworzenia całego klastra (a nie pojedynczej bazy jak przy pg_dump). Typowe pomyłki, które prowadzą do nieudanego odtworzenia, to brak skonfigurowanego dostępu replikacyjnego w pg_hba.conf, za niski max_wal_senders, albo pobranie plików danych bez towarzyszącego WAL - wtedy odtworzony klaster nie jest spójny i nie wstaje.
Backup fizyczny to kopia bajtowa katalogu danych (PGDATA). Ponieważ baza w trakcie kopiowania cały czas zmienia pliki, prosta kopia katalogu byłaby niespójna. pg_basebackup rozwiązuje to tak: łączy się po protokole replikacji, zaznacza w bazie początek backupu, kopiuje wszystkie pliki, a równocześnie pobiera segmenty WAL powstałe w trakcie kopiowania. Dzięki temu dostajesz spójny obraz, który da się odtworzyć, choć powstał na żywej bazie.
W odróżnieniu od pg_dump, kopia fizyczna jest związana z konkretną wersją główną PostgreSQL i architekturą - nie przeniesiesz jej między wersjami. Za to odtwarza się błyskawicznie (to gotowe pliki, nic się nie wykonuje od nowa) i obejmuje cały klaster naraz: wszystkie bazy, role i konfiguracje. Jest też punktem wyjścia do ciągłej archiwizacji i PITR - backup bazowy plus zarchiwizowane WAL pozwalają odtworzyć bazę do dowolnej chwili.
postgresql.conf ustaw wal_level = replica (domyślne w nowszych wersjach) i max_wal_senders na co najmniej 2, po czym w razie zmiany zrestartuj serwer.pg_hba.conf, dodając wiersz dla użytkownika z prawem REPLICATION, np. host replication replikator 10.0.0.0/24 scram-sha-256, i przeładuj konfigurację przez SELECT pg_reload_conf();.CREATE ROLE replikator WITH REPLICATION LOGIN PASSWORD 'haslo';. To nim będzie się łączył pg_basebackup.pg_basebackup -h serwer_zrodlowy -U replikator -D /backup/pgdata -Fp -Xs -P -R. Opcja -Xs pobiera WAL strumieniowo (spójność), a -R tworzy od razu plik konfiguracji recovery, przydatny dla repliki.-R ustawi tryb standby i połączenie do primary. Jeśli to samodzielny serwer, po prostu wystartuj usługę - PostgreSQL sam dokona recovery na podstawie pobranego WAL i wstanie w spójnym stanie.Sprawdź w logu startu, że klaster przeszedł recovery i osiągnął spójny punkt (komunikaty o odtwarzaniu WAL i o gotowości do przyjmowania połączeń). Połącz się i potwierdź, że bazy istnieją: \l w psql pokaże wszystkie bazy z kopii. Zwaliduj liczbę wierszy w kluczowej tabeli i porównaj z oryginałem. Jeśli stawiasz replikę, sprawdź na primary SELECT client_addr, state, sync_state FROM pg_stat_replication; - powinien pojawić się wiersz dla nowej repliki w stanie streaming, a na replice SELECT pg_is_in_recovery(); zwróci true.
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...