Blog JSystems - uwalniamy wiedzę!

Szukaj

PostgreSQL

Jak zrobić gorący backup fizyczny (pg_basebackup)

W skrócie

  • Chcesz zrobić pełną kopię fizyczną działającej bazy PostgreSQL bez jej zatrzymywania, ale nie wiesz, jak poprawnie użyć pg_basebackup i jak potem taki backup odtworzyć.
  • Kopia fizyczna to bajtowy obraz całego klastra. Żeby zrobić ją na działającej bazie, trzeba spójnie objąć pliki danych i towarzyszący im WAL, a następnie odtworzyć klaster w trybie recovery.
  • Przygotuj dostęp replikacyjny, uruchom pg_basebackup z docelowym katalogiem i strumieniem WAL, a odtworzenie polega na wystartowaniu klastra z tak pobranych plików.

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.

Jak to wygląda w praktyce

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.

Dlaczego tak się dzieje

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.

Jak to rozwiązać krok po kroku

  1. Przygotuj serwer źródłowy. W 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.
  2. Zezwól na połączenie replikacyjne w 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();.
  3. Utwórz użytkownika do backupu, jeśli go nie masz: CREATE ROLE replikator WITH REPLICATION LOGIN PASSWORD 'haslo';. To nim będzie się łączył pg_basebackup.
  4. Wykonaj gorący backup do pustego katalogu docelowego, ze strumieniem WAL i paskiem postępu: 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.
  5. Aby odtworzyć pełny klaster, zatrzymaj docelowy serwer, podmień jego katalog danych na pobrane pliki (zachowując właściciela i uprawnienia, zwykle użytkownik postgres) i sprawdź, że uprawnienia katalogu to 0700.
  6. Wystartuj klaster z odtworzonych plików. Jeśli to ma być replika, plik utworzony przez -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.

Jak sprawdzić, że zadziałało

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

Szkolenie Administracja, replikacja i tuning baz danych 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

Szkolenie Zaawansowana administracja PostgreSQL - HA, DR, monitoring, skalowanie

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

Najczęściej zadawane pytania

Czym różni się pg_basebackup od pg_dump?
pg_basebackup robi kopię fizyczną całego klastra jako bajtowy obraz plików, związaną z wersją i architekturą. pg_dump tworzy przenośny backup logiczny pojedynczej bazy. Kopia fizyczna odtwarza się szybciej i obejmuje wszystkie bazy naraz.
Czy pg_basebackup wymaga zatrzymania bazy danych?
Nie, to backup gorący wykonywany na działającej bazie. pg_basebackup łączy się po protokole replikacji i równocześnie pobiera pliki danych oraz towarzyszący WAL, dzięki czemu otrzymany obraz jest spójny mimo pracy serwera.
Po co jest opcja -Xs w pg_basebackup?
Opcja -Xs pobiera segmenty WAL strumieniowo w trakcie kopiowania plików danych. Bez nich odtworzony klaster mógłby być niespójny, bo brakowałoby zmian powstałych podczas backupu. To ona zapewnia, że backup da się odtworzyć.
Czy kopię z pg_basebackup można odtworzyć na nowszej wersji PostgreSQL?
Nie, backup fizyczny jest związany z konkretną wersją główną i architekturą, więc nie przenosi się między wersjami. Do migracji na nowszą wersję użyj backupu logicznego pg_dump albo replikacji logicznej, które są przenośne.

Komentarze (0)

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

Brak komentarzy...