Używanie Barmana do tworzenia kopii zapasowych PostgreSQL — przegląd

Kopie zapasowe baz danych odgrywają kluczową rolę w projektowaniu skutecznej strategii odzyskiwania po awarii dla produkcyjnych baz danych. Administratorzy i architekci baz danych muszą stale pracować nad zaprojektowaniem optymalnej i skutecznej strategii tworzenia kopii zapasowych dla baz danych o znaczeniu krytycznym w czasie rzeczywistym, a także zapewnić spełnienie warunków umów SLA dotyczących odzyskiwania po awarii. Z mojego doświadczenia wynika, że ​​nie jest to łatwe i osiągnięcie nienagannej strategii tworzenia kopii zapasowych może zająć od kilku dni do kilku tygodni. To po prostu nie jest napisanie dobrego skryptu do tworzenia kopii zapasowych baz danych i upewnienie się, że działa. Należy wziąć pod uwagę kilka czynników, przyjrzyjmy się im:

• Rozmiar bazy danych: Rozmiar bazy danych odgrywa ważną rolę podczas projektowania strategii tworzenia kopii zapasowych. W rzeczywistości jest to jeden z podstawowych czynników definiujących
  • Czas potrzebny na wykonanie kopii zapasowej
  • Obciążenie komponentów infrastruktury, takich jak dysk, sieć, procesor itp.
  • Wymagana ilość miejsca na kopie zapasowe i związane z tym koszty
  • Jeśli bazy danych są hostowane w chmurze, koszty przechowywania kopii zapasowych zależą od wymaganej ilości miejsca
  • Ponadto rozmiar bazy danych wpływa na RTO
• Infrastruktura: Strategia tworzenia kopii zapasowych w dużym stopniu opiera się na infrastrukturze baz danych. Procedura tworzenia kopii zapasowej byłaby inna dla baz danych hostowanych na fizycznym serwerze w lokalnym centrum danych w porównaniu z tymi hostowanymi w chmurze.
• Lokalizacja kopii zapasowej: Gdzie są kopie zapasowe? Ogólnie rzecz biorąc, kopie zapasowe będą umieszczane w zdalnej lokalizacji, na przykład na taśmie lub w pamięci masowej w chmurze, takiej jak AWS S3.
• Narzędzie do tworzenia kopii zapasowych: Zidentyfikuj optymalne narzędzie do wykonywania kopii zapasowej bazy danych online, które potencjalnie zapewnia spójne tworzenie kopii zapasowych.

Dobra strategia tworzenia kopii zapasowych bazy danych musi zapewniać spełnienie RTO (cel czasu odzyskiwania) i RPO (cel punktu odzyskiwania), co z kolei pomaga osiągnąć cel odzyskiwania po awarii. Kopie zapasowe na poziomie systemu plików można wykonywać w bazach danych PostgreSQL na kilka sposobów. W tym blogu skupię się na narzędziu o nazwie Barman, które jest powszechnie używane do wykonywania kopii zapasowych baz danych PostgreSQL.

Barman (menedżer tworzenia kopii zapasowych i odzyskiwania) to oparte na Pythonie narzędzie open-source opracowane przez programistów z 2nd Quadrant. To narzędzie zostało opracowane w celu osiągnięcia strategii tworzenia kopii zapasowych baz danych klasy korporacyjnej dla krytycznych baz danych produkcyjnych PostgreSQL. Jego cechy i cechy przypominają RMAN firmy Oracle. Moim zdaniem barman jest jedną z najlepszych opcji dla baz danych PostgreSQL i może zapewnić szereg korzyści z perspektywy operacyjnej administratorom baz danych i inżynierom infrastruktury.

Przyjrzyjmy się niektórym możliwościom Barmana:

Zacznę od przeglądu konfiguracji, a następnie wymienię, jakiego rodzaju kopie zapasowe można wykonać

Technicznie rzecz biorąc, barman-cli jest narzędziem opartym na Pythonie i ma do czynienia z dwoma różnymi plikami konfiguracyjnymi. Jeden plik, który jest faktyczną konfiguracją bazy danych, która ma zostać zarchiwizowana, znajduje się w nazwach „/etc/barman.d” jako .conf, a drugi plik, który zawiera parametry związane z barmanem (takie jak Lokalizacja kopii zapasowych barmana, serwer barmana, pliki dziennika itp.) skonfigurowana znajduje się w „/etc” (/etc/barman.conf). Pliki konfiguracyjne barmana mają konfigurację parametrów typu MySQL.

Przykładowa zawartość pliku /etc/barman.conf jest pokazana poniżej

[barman]
barman_user = barman            ---------> barman user who performs backup/recovery of database
configuration_files_directory = /etc/barman.d    -----> location for DB configuration files
barman_home = /dbbackups/barman    ---> barman home directory
log_file = /dbbackups/barman/logs/barman.log ---> barman log file location
log_level = INFO  -----> level of logging for barman operations
compression = gzip  ----->  backups must be compressed

Instalacja Barmana

Przyjrzyjmy się procedurze instalacji barmana -

Instalacja ze źródła

Pobierz barmana z https://www.pgbarman.org/

Rozpakuj / rozpakuj instalator i wykonaj następujące polecenie jako użytkownik root -

[[email protected] barman-2.4]# ./setup.py install
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'setup_requires'
  warnings.warn(msg)
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires'
  warnings.warn(msg)
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'tests_require'
  warnings.warn(msg)
running install
running build
running build_py
creating build
creating build/lib
creating build/lib/barman
copying barman/utils.py -> build/lib/barman
copying barman/fs.py -> build/lib/barman
copying barman/retention_policies.py -> build/lib/barman
copying barman/diagnose.py -> build/lib/barman
copying barman/backup.py -> build/lib/barman
copying barman/recovery_executor.py -> build/lib/barman
copying barman/backup_executor.py -> build/lib/barman
copying barman/config.py -> build/lib/barman
copying barman/process.py -> build/lib/barman
copying barman/output.py -> build/lib/barman
copying barman/__init__.py -> build/lib/barman
copying barman/remote_status.py -> build/lib/barman
copying barman/xlog.py -> build/lib/barman
copying barman/lockfile.py -> build/lib/barman
copying barman/postgres.py -> build/lib/barman
copying barman/server.py -> build/lib/barman
copying barman/cli.py -> build/lib/barman
copying barman/version.py -> build/lib/barman
copying barman/compression.py -> build/lib/barman
copying barman/wal_archiver.py -> build/lib/barman
copying barman/infofile.py -> build/lib/barman
copying barman/exceptions.py -> build/lib/barman
copying barman/hooks.py -> build/lib/barman
copying barman/copy_controller.py -> build/lib/barman
copying barman/command_wrappers.py -> build/lib/barman
running build_scripts
creating build/scripts-2.7
copying and adjusting bin/barman -> build/scripts-2.7
changing mode of build/scripts-2.7/barman from 644 to 755
running install_lib
creating /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/utils.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/fs.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/retention_policies.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/diagnose.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/backup.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/recovery_executor.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/backup_executor.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/config.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/process.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/output.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/__init__.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/remote_status.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/xlog.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/lockfile.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/postgres.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/server.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/cli.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/version.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/compression.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/wal_archiver.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/infofile.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/exceptions.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/hooks.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/copy_controller.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/command_wrappers.py -> /usr/lib/python2.7/site-packages/barman
byte-compiling /usr/lib/python2.7/site-packages/barman/utils.py to utils.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/fs.py to fs.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/retention_policies.py to retention_policies.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/diagnose.py to diagnose.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/backup.py to backup.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/recovery_executor.py to recovery_executor.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/backup_executor.py to backup_executor.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/config.py to config.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/process.py to process.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/output.py to output.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/__init__.py to __init__.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/remote_status.py to remote_status.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/xlog.py to xlog.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/lockfile.py to lockfile.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/postgres.py to postgres.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/server.py to server.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/cli.py to cli.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/version.py to version.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/compression.py to compression.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/wal_archiver.py to wal_archiver.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/infofile.py to infofile.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/exceptions.py to exceptions.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/hooks.py to hooks.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/copy_controller.py to copy_controller.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/command_wrappers.py to command_wrappers.pyc
running install_scripts
copying build/scripts-2.7/barman -> /usr/bin
changing mode of /usr/bin/barman to 755
running install_data
copying doc/barman.1 -> /usr/share/man/man1
copying doc/barman.5 -> /usr/share/man/man5
running install_egg_info
Writing /usr/lib/python2.7/site-packages/barman-2.4-py2.7.egg-info

Instalowanie z repozytorium

Instalację można również przeprowadzić przez mniam w następujący sposób

[[email protected]~]$ yum install barman

Przyjrzyjmy się różnym typom kopii zapasowych obsługiwanych przez barmana

Fizyczne gorące kopie zapasowe

Barman obsługuje fizyczne kopie zapasowe na gorąco, co oznacza tworzenie kopii zapasowych online fizycznych plików danych i plików dziennika transakcji bazy danych przy użyciu metodologii rsync, która może być również skompresowana.

Rzućmy okiem na kroki i polecenia, aby wykonać kopię zapasową RSYNC za pomocą barmana

#1 plik konfiguracyjny bazy danych PostgreSQL dla barmana

[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
ssh_command=ssh [email protected]
archiver=on
backup_method = rsync

„pgdb” to identyfikator bazy danych Postgres dla barmana, a nazwą pliku konfiguracyjnego powinien być .conf znajdujący się w /etc/barman.d/. Po wykonaniu polecenia kopii zapasowej barmana, barman szuka sekcji [pgdb] w pliku pgdb.conf.

Parametr backup_method określa typ kopii zapasowej do wykonania. W tym przypadku backup_method to rsync.

Uwaga:Aby polecenie barman backup zakończyło się powodzeniem, uwierzytelnianie ssh bez hasła musi być skonfigurowane między serwerami barman i postgres.

#2 parametry pliku postgresql.conf

wal_level=replica
archive_mode=on
archive_command=’rsync to <ARCHIVE LOCATION>’

Polecenie kopii zapasowej Barmana

#3 Sprawdź, czy barman jest gotowy do wykonywania kopii zapasowych

[[email protected] pgdb]$ barman check pgdb
Server pgdb:
        PostgreSQL: OK
        is_superuser: OK
        wal_level: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 4 backups, expected at least 0)
        ssh: OK (PostgreSQL server)
        not in recovery: OK
        archive_mode: OK
        archive_command: OK
        continuous archiving: OK
        archiver errors: OK

Powyższe dane wyjściowe mówią, że wszystko jest „OK”, aby kontynuować tworzenie kopii zapasowej, co oznacza, że ​​dobrze jest zrobić kopię zapasową.

Na przykład, poniżej dane wyjściowe mówią, że nie można wykonać kopii zapasowej, ponieważ według barmana SSH nie działa -

[[email protected]  ~]$ barman check pgdb
Server pgdb:
        PostgreSQL: OK
        is_superuser: OK
        wal_level: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 0 backups, expected at least 0)
        ssh: FAILED (Connection failed using '[email protected] -o BatchMode=yes -o StrictHostKeyChecking=no' return code 127)
        not in recovery: OK
        archive_mode: OK
        archive_command: OK
        continuous archiving: OK
        archiver errors: OK

#4 Wykonaj kopię zapasową bazy danych

[[email protected] ~]$ barman backup pgdb
Starting backup using rsync-exclusive method for server pgdb in /dbbackup/barman_backups/pgdb/base/20180816T153846
Backup start at LSN: 0/1C000028 (00000001000000000000001C, 00000028)
This is the first backup for server pgdb
WAL segments preceding the current backup have been found:
        00000001000000000000000B from server pgdb has been removed
        00000001000000000000000C from server pgdb has been removed
        00000001000000000000000D from server pgdb has been removed
        00000001000000000000000E from server pgdb has been removed
        00000001000000000000000F from server pgdb has been removed
        000000010000000000000010 from server pgdb has been removed
        000000010000000000000011 from server pgdb has been removed
        000000010000000000000012 from server pgdb has been removed
        000000010000000000000013 from server pgdb has been removed
        000000010000000000000014 from server pgdb has been removed
        000000010000000000000015 from server pgdb has been removed
        000000010000000000000016 from server pgdb has been removed
Starting backup copy via rsync/SSH for 20180816T153846
Copy done (time: 1 second)
This is the first backup for server pgdb
Asking PostgreSQL server to finalize the backup.
Backup size: 21.8 MiB
Backup end at LSN: 0/1C0000F8 (00000001000000000000001C, 000000F8)
Backup completed (start time: 2018-08-16 15:38:46.668492, elapsed time: 1 second)
Processing xlog segments from file archival for pgdb
        000000010000000000000016
        000000010000000000000017
        000000010000000000000018
        000000010000000000000019
        00000001000000000000001A
        00000001000000000000001B
        00000001000000000000001C
        00000001000000000000001C.00000028.backup

Aby zrozumieć, czy polecenie tworzenia kopii zapasowej barmana w ogóle się powiedzie, poniższe polecenie pomaga -

Przyrostowe kopie zapasowe

Kolejną wielką zdolnością Barmana jest możliwość wykonywania przyrostowych kopii zapasowych. Oznacza to, że można utworzyć kopię zapasową tylko bloków zmienionych od czasu ostatniej pełnej kopii zapasowej bazy danych. W przypadku baz danych, które podlegają mniejszym zmianom danych, przyrostowe tworzenie kopii zapasowych może zmniejszyć zużycie zasobów.

W dużym stopniu zależy od rsync i twardych linków. Poniżej znajdują się zalety przyrostowych kopii zapasowych –

• Znacznie skraca dzienny czas tworzenia kopii zapasowych
• Ilość danych, których kopia zapasowa jest tworzona, zmniejsza się, ponieważ kopie zapasowe będą tworzone tylko dla zmienionych bloków danych, co z kolei zmniejsza wykorzystanie zasobów infrastruktury, takich jak przepustowość sieci, miejsce na dysku, operacje we/wy itp.
• Jeśli chcesz osiągnąć bardzo dobry RTO, jest to funkcja, której byś szukał

Polecenia tworzenia przyrostowej kopii zapasowej są prawie takie same. Wszelkie kolejne kopie zapasowe po wykonaniu pierwszej kopii zapasowej za pomocą opcji backup_method=rsync będą przyrostowe kopie zapasowe, a barman wyciągnie WAL za pomocą narzędzia pg_recievexlog.

Zdalne kopie zapasowe i odzyskiwanie baz danych

Moim zdaniem ta zdolność Barmana jest bardzo korzystna dla administratorów baz danych. W pierwszej kolejności administratorzy baz danych powinni unikać obciążania zasobów serwera produkcyjnej bazy danych w jak największym stopniu podczas tworzenia kopii zapasowych, a wykonywanie ich zdalnie byłoby najlepszą opcją. Barman wykorzystuje pg_basebackup, co znacznie ułatwia pisanie skryptów i ich automatyzację.

Ogólnie rzecz biorąc, tradycyjnie dostępnymi opcjami automatycznego tworzenia kopii zapasowych będą -

1. pg_basebackup
2. kopia smołowa

Powyższe dwie opcje obejmują wiele prac programistycznych i testowych, aby zapewnić skuteczną strategię tworzenia kopii zapasowych, aby spełnić wymagania umów SLA i mogą stanowić wyzwania dla dużych baz danych z wieloma obszarami tabel.

Z Barmanem to całkiem proste. Kolejną wyjątkową zdolnością barmana jest ciągłe przesyłanie strumieniowe WAL. Przyjrzyjmy się temu bardziej szczegółowo.

Streaming Backup z ciągłym przesyłaniem strumieniowym WAL

To sprawia, że ​​barman wyróżnia się na tle innych narzędzi na rynku. Pliki WAL na żywo można przesyłać strumieniowo w sposób ciągły do ​​zdalnej lokalizacji kopii zapasowej za pomocą programu Barman. Jest to FUNKCJA, którą administratorzy baz danych byliby zachwyceni. Byłem podekscytowany, że się o tym dowiedziałem. Osiągnięcie tego jest niezwykle trudne lub prawie niemożliwe za pomocą ręcznie budowanych skryptów lub kombinacji narzędzi, takich jak pg_basebackup i pg_receivewal. Dzięki ciągłemu strumieniowaniu WAL można osiągnąć lepsze RPO. Jeśli strategia tworzenia kopii zapasowych jest starannie zaprojektowana, nie będzie przesadą stwierdzenie, że można osiągnąć prawie 0 RPO.

Przyjrzyjmy się krokom, poleceniom wykonywania kopii zapasowej strumieniowego barmana

#1 zmiany parametru postgresql.conf

Następujące konfiguracje do wykonania w pliku postgresql.conf

wal_level=replica
max_wal_senders = 2
max_replication_slots = 2
synchronous_standby_names = 'barman_receive_wal'
archive_mode=on
archive_command = 'rsync -a %p [email protected]:INCOMING_WAL_DIRECTORY/%f'
archive_timeout=3600 (should not be 0 or disabled)

#2 Utwórz gniazdo replikacji za pomocą barmana

Gniazdo replikacji jest ważne w przypadku przesyłania strumieniowego kopii zapasowych. W przypadku niepowodzenia ciągłego przesyłania strumieniowego WAL z jakiegokolwiek powodu, wszystkie nieprzesyłane strumienie WAL mogą zostać zachowane w bazie danych postgres bez ich usuwania.

[[email protected] ~]$ barman receive-wal --create-slot pgdb
Creating physical replication slot 'barman' on server 'pgdb'
Replication slot 'barman' created

#3 Skonfiguruj plik konfiguracyjny serwera bazy danych dla barmana

Identyfikator bazy danych barmana to „pgdb”. Plik konfiguracyjny o nazwie pgdb.conf musi zostać utworzony w lokalizacji /etc/barman.d/ z następującą zawartością

[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
streaming_conninfo=host=pgserver user=barman
backup_method=postgres
archiver=on
incoming_wals_directory=/dbbackups/barman_backups/pgdb/incoming
streaming_archiver=on
slot_name=barman

streaming_conninfo jest parametrem do skonfigurowania dla barmana do wykonywania strumieniowych kopii zapasowych
metoda_kopii_zapasowej musi być skonfigurowany jako „postgres”, gdy ma być wykonywana kopia zapasowa strumieniowa
streaming_archiver musi być skonfigurowany jako „on”
slot_name=barman Ten parametr musi być skonfigurowany, gdy barman ma używać gniazd replikacji. W tym przypadku nazwa gniazda replikacji to barman

Po zakończeniu konfiguracji wykonaj kontrolę barmana, aby upewnić się, że strumieniowe kopie zapasowe będą działać pomyślnie.

#4 Sprawdź, czy odbiór barmana działa prawidłowo

Ogólnie rzecz biorąc, dla pierwszego barmana-wal odbierania nie działa natychmiast po zmianach konfiguracji, może wystąpić błąd, a polecenie barman check może pokazać następujące -

[[email protected]  archive_status]$ barman check pgdb
Server pgdb:
        PostgreSQL: OK
        is_superuser: OK
        PostgreSQL streaming: OK
        wal_level: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 0 backups, expected at least 0)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        archive_mode: OK
        archive_command: OK
        continuous archiving: OK
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: FAILED (See the Barman log file for more details)
        archiver errors: OK

Kiedy prowadzisz barmana Receive-wal, może się zawiesić. Aby otrzymać-wal działał poprawnie za pierwszym razem, poniższe polecenie musi zostać wykonane.

[[email protected]  arch_logs]$ barman cron
Starting WAL archiving for server pgdb
Starting streaming archiver for server pgdb

Teraz zrób jeszcze raz kontrolę barmana, teraz powinno być dobrze.

[[email protected]  arch_logs]$ barman check pgdb
Server pgdb:
        PostgreSQL: OK
        is_superuser: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 2 backups, expected at least 0)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        archive_mode: OK
        archive_command: OK
        continuous archiving: OK
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: OK
        archiver errors: OK

Jeśli widzisz, status Receivexlog pokazuje OK. To jeden z problemów, z jakimi się zmierzyłem.

#5 Sprawdź, czy barman jest gotowy do wykonywania kopii zapasowych

[[email protected] ~]$ barman check pgdb
Server pgdb:
        PostgreSQL: OK
        is_superuser: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 4 backups, expected at least 0)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        archive_mode: OK
        archive_command: OK
        continuous archiving: OK
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: OK
        archiver errors: OK

#6 Sprawdź stan transmisji za pomocą barmana

[[email protected] pgdb]$ barman replication-status pgdb
Status of streaming clients for server 'pgdb':
  Current LSN on master: 0/250008A8
  Number of streaming clients: 1

  1. #1 Sync WAL streamer
     Application name: barman_receive_wal
     Sync stage      : 3/3 Remote write
     Communication   : TCP/IP
     IP Address      : 192.168.1.10 / Port: 52602 / Host: -
     User name       : barman
     Current state   : streaming (sync)
     Replication slot: barman
     WAL sender PID  : 26592
     Started at      : 2018-08-16 16:03:21.422430+10:00
     Sent LSN   : 0/250008A8 (diff: 0 B)
     Write LSN  : 0/250008A8 (diff: 0 B)
     Flush LSN  : 0/250008A8 (diff: 0 B)

Powyższy status oznacza, że ​​barman jest gotowy do wykonania backupu strumieniowego. Wykonaj kopię zapasową, jak pokazano poniżej -

[[email protected] arch_logs]$ barman backup pgdb
Starting backup using postgres method for server pgdb in /dbbackup/barman_backups/pgdb/base/20180816T160710
Backup start at LSN: 0/1F000528 (00000001000000000000001F, 00000528)
Starting backup copy via pg_basebackup for 20180816T160710
Copy done (time: 1 second)
Finalising the backup.
Backup size: 21.9 MiB
Backup end at LSN: 0/21000000 (000000010000000000000020, 00000000)
Backup completed (start time: 2018-08-16 16:07:10.401526, elapsed time: 1 second)
Processing xlog segments from file archival for pgdb
        00000001000000000000001F
        000000010000000000000020
        000000010000000000000020.00000028.backup
        000000010000000000000021
Processing xlog segments from streaming for pgdb
        00000001000000000000001F
        000000010000000000000020

Scentralizowane i skatalogowane kopie zapasowe

Jest bardzo korzystny w środowiskach, w których działa wiele baz danych na wielu serwerach w środowisku sieciowym. To jedna z wyjątkowych cech Barmana. Pracowałem w środowiskach czasu rzeczywistego, w których musiałem zarządzać, administrować setkami baz danych i zawsze czułem potrzebę scentralizowanych kopii zapasowych baz danych i dlatego Oracle RMAN stał się popularny w strategii tworzenia kopii zapasowych baz danych Oracle i teraz Barman to wypełnia miejsce na PostgreSQL. Dzięki Barman, inżynierowie DBA i DevOps mogą pracować nad stworzeniem scentralizowanego serwera kopii zapasowych, w którym kopie zapasowe wszystkich baz danych są utrzymywane i sprawdzane.

Skatalogowane kopie zapasowe, co oznacza, że ​​barman utrzymuje scentralizowane repozytorium, w którym utrzymywane są statusy wszystkich kopii zapasowych. Możesz sprawdzić kopie zapasowe dostępne dla określonej bazy danych, jak pokazano poniżej -

[[email protected] ~]$  barman list-backup pgdb
pgdb 20180816T160924 - Thu Aug 16 16:09:25 2018 - Size: 22.0 MiB - WAL Size: 135.7 KiB
pgdb 20180816T160710 - Thu Aug 16 16:07:11 2018 - Size: 21.9 MiB - WAL Size: 105.8 KiB
pgdb 20180816T153913 - Thu Aug 16 15:39:15 2018 - Size: 21.9 MiB - WAL Size: 54.2 KiB
pgdb 20180816T153846 - Thu Aug 16 15:38:48 2018 - Size: 21.9 MiB - WAL Size: 53.0 KiB

Zasady przechowywania kopii zapasowych

Zasady przechowywania można zdefiniować dla kopii zapasowych bazy danych. Kopie zapasowe mogą stać się przestarzałe po pewnym czasie, a przestarzałe kopie zapasowe mogą być usuwane od czasu do czasu.

W pliku konfiguracyjnym znajdują się opcje, które zapewniają, że kopie zapasowe są zachowywane i stają się przestarzałe, gdy okres przechowywania przekroczy -

Pierwszy parametr do skonfigurowania to minimum_redundancy . Zawsze konfiguruj minimum_redundancy na>0, aby mieć pewność, że kopie zapasowe nie zostaną przypadkowo usunięte.

Przykład:minimalna_redundancja =1

• retention_policy parametr określi, jak długo podstawowe kopie zapasowe muszą być przechowywane, aby zapewnić spełnienie warunków SLA dotyczących odzyskiwania po awarii.
• wal_retention_policy Parametr określa, jak długo kopie zapasowe wal muszą być przechowywane. Zapewnia to spełnienie oczekiwanego RPO.

Istniejące zasady przechowywania i nadmiarowości dla serwera bazy danych można sprawdzić za pomocą polecenia barman check w następujący sposób

[[email protected] ~]$ barman check pgdb
Server pgdb:
        PostgreSQL: OK
        is_superuser: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 4 backups, expected at least 0)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        archive_mode: OK
        archive_command: OK
        continuous archiving: OK
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: OK
        archiver errors: OK

Równoległe kopie zapasowe i odzyskiwanie można to zrobić przy użyciu wielu procesorów, co naprawdę przyspiesza tworzenie kopii zapasowych i odzyskiwanie. Ta funkcja jest korzystna dla bardzo dużych baz danych o wielkości do Terabajtów.

Aby wykonywać kopie zapasowe równolegle, dodaj następującą opcję w pliku konfiguracyjnym serwera bazy danych (jest to plik /etc/barman.d/pgdb.conf)-

parallel_jobs = 1

Mogę zakończyć stwierdzeniem, że barman jest narzędziem klasy korporacyjnej, które może potencjalnie pomóc administratorom baz danych zaprojektować skuteczną strategię odzyskiwania po awarii.