Dzięki nowym narzędziom barman-cloud-restore i barman-cloud-wal-restore wprowadzone w Barman 2.11 , możliwe jest teraz odzyskanie instancji PostgreSQL przy użyciu pełnej kopii zapasowej wykonanej wcześniej przy użyciu barman-cloud-wal-archive i barman-cloud-backup polecenia. Odkryjmy razem, jak to zaimplementować w następnym artykule.
Warto zauważyć, że w Barman 2.11 wszystkie narzędzia chmurowe dla Barmana znajdują się teraz w osobnym pakiecie o nazwie barman-cli-cloud .
Wymagania
1. barman-cli-cloud pakiet
2. Instancja PostgreSQL
3. Łyżka AWS S3
4. Druga maszyna wirtualna, na której należy wykonać przywracanie
W tym artykule przetestujemy barman-cli-cloud funkcjonalności w maszynie wirtualnej z Debian Buster i PostgreSQL 12. Aby prawidłowo postępować zgodnie z instrukcjami zawartymi w tym artykule, zakładamy również, że masz:
- skonfigurowano Postgres do archiwizowania plików WAL w istniejącym zasobniku S3 przy użyciu
barman-cloud-wal-archive - wykonał kopię zapasową i wyślij ją do tego samego wiadra S3 przez
barman-cloud-backup
Możesz to łatwo osiągnąć, postępując zgodnie z instrukcjami zawartymi w tych poprzednich artykułach na blogu:
- Chmura Barmana – Część 1:Archiwum WAL
- Chmura Barmana – Część 2:Kopia zapasowa w chmurze
Skonfiguruj serwer odzyskiwania
W rezultacie mamy wiadro S3 na AWS o nazwie barman-s3-test który zawiera już pliki WAL i kopię zapasową zarchiwizowaną przez barman-cloud-wal-archive i barman-cloud-backup narzędzi, teraz musimy poprawnie skonfigurować serwer, który będzie hostem do odzyskiwania instancji PostgreSQL.
1. Zainstaluj PostgreSQL 12 z oficjalnego repozytorium PGDG
2. Zainstaluj publiczne repozytorium drugiej kwadrantu
3. Zainstaluj barman-cli-cloud pakiet:
example@sqldat.com:~# apt update example@sqldat.com:~# apt install barman-cli-cloud
4. Zainstaluj awscli pakiet:
example@sqldat.com:~# apt install awscli
5. Skonfiguruj poświadczenia AWS za pomocą narzędzia awscli jako użytkownik postgres:
example@sqldat.com:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
Wykonaj procedurę przywracania
Teraz, gdy serwer odzyskiwania jest poprawnie skonfigurowany, jesteśmy gotowi do rozpoczęcia procedury przywracania.
Barman 2.11 przedstawia barman-cloud-backup-list polecenie, które pozwala na pobranie informacji o kopiach zapasowych wykonanych za pomocą barman-cloud-backup :
example@sqldat.com:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12 Backup ID End Time Begin Wal 20200713T120856 2020-07-13 12:09:05 00000001000000000000000C
Jesteśmy teraz gotowi do wykonania przywracania za pomocą barman-cloud-restore polecenie:
example@sqldat.com:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/
Po pomyślnym zakończeniu przywracania możemy sprawdzić zawartość katalogu PGDATA:
example@sqldat.com:~$ ls /var/lib/postgresql/12/main/ PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf backup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.conf base pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact
Teraz, aby mieć pewność, że proces przywracania przebiegł prawidłowo, musimy uruchomić odzyskaną instancję PostgreSQL i sprawdzić, czy wszystko działa zgodnie z oczekiwaniami. Ten proces wymaga kilku dodatkowych kroków.
Po pierwsze, ponieważ pracujemy w systemie Debian, musimy skopiować pliki zawierające konfigurację PostgreSQL do katalogu /etc/postgresql/12/main/ katalog:
example@sqldat.com:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/ example@sqldat.com:~$ cp /var/lib/postgresql/12/main/pg_hba.conf /etc/postgresql/12/main/ example@sqldat.com:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/
Po drugie, utwórz recovery.signal plik:
example@sqldat.com:~$ touch /var/lib/postgresql/12/main/recovery.signal
Następnie wyłącz archive_command aby zapobiec zapisywaniu odzyskanej instancji w tym samym zasobniku, co oryginalna instancja:
example@sqldat.com:~$ echo \"archive_command = 'cd .'\" >> /etc/postgresql/12/main/postgresql.conf
Następnie musisz skonfigurować PostgreSQL, aby pobierał pliki WAL z najnowszej dostępnej osi czasu z zasobnika S3 za pomocą barman-cloud-wal-restore w restore_command :
example@sqldat.com:~$ echo \"restore_command = 'barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\" >> /etc/postgresql/12/main/postgresql.conf example@sqldat.com:~$ echo \"recovery_target_timeline = 'latest'\" >> /etc/postgresql/12/main/postgresql.conf
WAŻNE :Przed kontynuowaniem upewnij się, że instancja PostgreSQL nie jest uruchomiona i że katalog docelowy (domyślny katalog danych PostgreSQL) jest pusty.
Wreszcie jesteśmy gotowi do uruchomienia nowej odzyskanej instancji:
example@sqldat.com:~# systemctl restart example@sqldat.com
Świetny! Jak widać z dziennika PostgreSQL, pliki WAL są odzyskiwane z zasobnika S3 i instancja została poprawnie uruchomiona:
example@sqldat.com:~$ less /var/log/postgresql/postgresql-12-main.log ... 2020-07-13 12:43:25.093 UTC [9458] LOG: starting PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 2020-07-13 12:43:25.093 UTC [9458] LOG: listening on IPv4 address "127.0.0.1", port 5432 2020-07-13 12:43:25.095 UTC [9458] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2020-07-13 12:43:25.111 UTC [9459] LOG: database system was interrupted; last known up at 2020-07-13 12:08:56 UTC 2020-07-13 12:43:25.508 UTC [9459] LOG: starting archive recovery 2020-07-13 12:43:26.010 UTC [9459] LOG: restored log file "00000001000000000000000C" from archive 2020-07-13 12:43:26.052 UTC [9459] LOG: redo starts at 0/C000028 2020-07-13 12:43:26.054 UTC [9459] LOG: consistent recovery state reached at 0/C000138 2020-07-13 12:43:26.054 UTC [9458] LOG: database system is ready to accept read only connections 2020-07-13 12:43:26.469 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:26.823 UTC [9459] LOG: redo done at 0/D0001B0 2020-07-13 12:43:27.242 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:27.592 UTC [9459] LOG: selected new timeline ID: 2 2020-07-13 12:43:27.644 UTC [9459] LOG: archive recovery complete 2020-07-13 12:43:27.979 UTC [9458] LOG: database system is ready to accept connections
Wniosek
Jak zwykle w przypadku każdej nowej wersji Barmana, zalecamy wszystkim zaktualizowanie swoich systemów do najnowszej wersji. Pełna lista zmian i poprawek błędów jest dostępna tutaj.
Pamiętaj, że jeśli już używasz barman-cloud-wal-archive lub barman-cloud-backup zainstalowany przez pakiet RPM/Apt i aktualizujesz swój system, musisz zainstalować barman-cli-cloud pakiet. Wynika to z faktu, że w wersji Barman 2.11 wszystkie narzędzia związane z chmurą są częścią barman-cli-cloud pakiet, jak wyjaśniono na początku artykułu.
Kolejne wersje Barmana mogą poprawić użyteczność i możliwości automatyzacji polecenia restore, na przykład przygotowując recovery.conf lub recovery.signal plik jak rzeczywisty Barman.
