Използване на Barman за архивиране на PostgreSQL

Архивирането на бази данни играе наложителна роля при проектирането на ефективна стратегия за възстановяване след бедствие за производствени бази данни. Администраторите на бази данни и архитектите трябва непрекъснато да работят за проектиране на оптимална и ефективна стратегия за архивиране за критични за мисия бази данни в реално време и допълнително да гарантират, че SLA за възстановяване след бедствие са изпълнени. Според моя опит това не е лесно и може да отнеме от дни до седмици, за да се постигне безупречна стратегия за архивиране. Просто не се пише добър скрипт за архивиране на бази данни и се уверете, че работи. Има няколко фактора, които трябва да вземете предвид, нека да ги разгледаме:

Размер на базата данни: Размерът на базата данни играе важна роля при проектирането на стратегии за архивиране. Всъщност това е един от основните фактори, които определят
- Време, необходимо на резервното копие
- Натоварването на инфраструктурните компоненти като диск, мрежа, процесор и др.
- Необходимото количество резервно хранилище и свързаните с това разходи
- Ако базите данни се хостват в облак, тогава разходите за съхранение на резервно копие зависят от необходимото количество хранилище.
- Освен това размерът на базата данни оказва влияние върху RTO
Инфраструктура: Стратегията за архивиране до голяма степен разчита на инфраструктурата на базите данни. Процедурата за архивиране би била различна за бази данни, хоствани на физически сървър в локален център за данни, в сравнение с тези, хоствани в облак.
Резервно местоположение: Къде отиват резервните копия? Обикновено резервните копия ще бъдат поставени на отдалечено място, например на лента или специфично за облак хранилище, като AWS S3.
Инструмент за архивиране: Идентифицирайте оптимален инструмент за извършване на онлайн архивиране на база данни, което потенциално гарантира, че е направено последователно архивиране.

Добрата стратегия за архивиране на база данни трябва да гарантира, че са изпълнени RTO (Цел за време за възстановяване) и RPO (Цел за точка на възстановяване), което от своя страна спомага за постигането на целта за възстановяване след бедствие. Архивирането на ниво файлова система може да се извършва на PostgreSQL бази данни по няколко начина. В този блог фокусът ми ще бъде върху инструмент, наречен Barman, който популярно се използва за извършване на архивиране на PostgreSQL база данни.

Barman (мениджър за архивиране и възстановяване) е базиран на Python инструмент с отворен код, разработен от разработчици във 2-ри квадрант. Този инструмент е разработен за постигане на стратегия за архивиране на база данни от корпоративен клас за критични за мисия производствени бази данни PostgreSQL. Неговите характеристики и характеристики наподобяват тези на RMAN на Oracle. Според мен, barman е една от най-добрите опции за PostgreSQL бази данни и може да предостави няколко предимства от гледна точка на операциите на администраторите на база данни и инженерите на инфраструктурата.

Нека разгледаме някои възможности на Barman:

Ще започна с преглед на конфигурацията и след това ще изброя какви архиви могат да се извършват

Технически, barman-cli е инструмент, базиран на python и има два различни конфигурационни файла, с които да се справя. Един файл, който е действителната конфигурация на базата данни, която трябва да бъде архивирана, се намира в имената на „/etc/barman.d“ като .conf, а другият файл, който има параметрите, свързани с barman (като Местоположение на резервни копия на barman, сървър на барман, лог файлове и т.н.), конфигурирани се намира в “/etc” (/etc/barman.conf). Конфигурационните файлове на барман имат конфигурация на параметри тип MySQL.

Примерно съдържание на файла /etc/barman.conf е показано по-долу

[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

Инсталиране на Barman

Нека да разгледаме процедурата за инсталиране на барман -

Инсталиране от източника

Изтеглете бармана от https://www.pgbarman.org/

Разархивирайте инсталатора и изпълнете следната команда като 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

Инсталиране от репо

Инсталацията може да се извърши и чрез yum, както следва

[[email protected]~]$ yum install barman

Нека да разгледаме различните видове резервни копия, които барман поддържа

Горещо физическо архивиране

Barman поддържа Physical Hot Backups, което означава, онлайн архивиране на файлове с физически данни и регистрационни файлове на транзакциите на базата данни, използвайки методологията на rsync, която може да бъде и в компресирана форма.

Нека да разгледаме стъпките и командите за извършване на RSYNC архивиране с помощта на barman

#1 PostgreSQL конфигурационен файл на база данни за барман

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

“pgdb” е идентификаторът на Postgres Database за barman и името на конфигурационния файл трябва да бъде .conf, намиращо се в /etc/barman.d/. Когато командата barman backup се изпълни, barman търси секцията [pgdb] във файла pgdb.conf.

Параметърът backup_method определя типа архивиране, което да се направи. В този случай backup_method е rsync.

Забележка:За да бъде успешна командата за архивиране на barman, трябва да се конфигурира ssh удостоверяване без парола между сървърите на barman и postgres.

#2 параметри на postgresql.conf файл

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

Резервна команда на Барман

#3 Проверете дали барманът е готов да извършва архивиране

[[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

Горният изход казва, че всичко е „ОК“, за да продължите с архивирането, което означава, че е добре да направите резервно копие.

Например, по-долу изходът казва, че архивирането не може да се направи, защото според бармен SSH не работи -

[[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 Извършване на архивиране на база данни

[[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

За да разберете дали командата за архивиране на бармен дори ще бъде успешна, командата по-долу помага -

Постепенно архивиране

Друга страхотна способност на Barman е способността да прави инкрементални архиви. Това означава, че само променените блокове след последното пълно архивиране на базата данни могат да бъдат архивирани. За бази данни, които претърпяват по-малко промени в данните, постепенното им архивиране може да намали използването на ресурси.

До голяма степен зависи от rsync и твърди връзки. По-долу са предимствата на инкременталното архивиране –

Намалява значително дневното време за архивиране
Обемът на архивираните данни намалява, тъй като само променените блокове данни ще бъдат архивирани, което от своя страна намалява използването на инфраструктурни ресурси като мрежова честотна лента, дисково пространство, I/O и др.
Ако след постигане на много добър RTO, това е функцията, която бихте търсили

Командите за инкрементално архивиране са почти същите. Всички последващи архиви след първото архивиране, направено с опция backup_method=rsync ще бъде инкрементално архивиране и барманът изтегля WAL с помощта на помощната програма pg_recievexlog.

Отдалечено архивиране и възстановяване на база данни

Според мен тази способност на Barman е много полезна за DBA. Първото нещо, което администраторите на база данни биха търсили, е да избягват да натоварват ресурсите на сървъра на производствената база данни, доколкото е възможно, по време на архивирането и извършването им от разстояние би било най-добрият вариант. Barman използва pg_basebackup, което го прави много по-лесно при скриптовете и автоматизирането му.

Като цяло, традиционно наличните опции за автоматично архивиране ще бъдат -

pg_basebackup
tar copy

Горните две опции включват много разработка и тестване, за да се гарантира, че е налице ефективна стратегия за архивиране, за да отговори на изискванията на SLA и може да създаде предизвикателства за големи бази данни с множество пространства за таблици.

С Barman е доста просто. Друга изключителна способност на бармана е непрекъснатото поточно предаване на WAL. Нека да разгледаме това малко по-подробно.

Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книга

Поточно архивиране с непрекъснато поточно предаване на WAL

Това прави бармана открояващ се в сравнение с други инструменти на пазара. WAL файловете на живо могат да се предават непрекъснато на отдалечено място за архивиране с помощта на Barman. Това е ХАРАКТЕРИСТИКАТА, която администраторите на база данни биха били развълнувани да знаят. Бях развълнуван да разбера за това. Изключително трудно или почти невъзможно е да се постигне това с ръчно създадени скриптове или с комбинация от инструменти като pg_basebackup и pg_receivewal. С непрекъснато поточно предаване на WAL може да се постигне по-добро RPO. Ако стратегията за архивиране е разработена внимателно, няма да е преувеличено да се каже, че може да се постигне почти 0 RPO.

Нека разгледаме стъпките, командите за извършване на поточно архивиране на бармен

#1 промени в параметрите на postgresql.conf

Следните конфигурации трябва да се направят в 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 Създайте слот за репликация с помощта на барман

Слотът за репликация е важен за поточно архивиране. В случай, че непрекъснатото поточно предаване на WAL се провали по някаква причина, всички непоточно предавани WAL могат да бъдат запазени в базата данни postgres, без да бъдат премахнати.

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

#3 Конфигурирайте конфигурационния файл на сървъра на база данни за барман

Идентификаторът на база данни за барман е „pgdb“. Конфигурационен файл, наречен pgdb.conf, трябва да бъде създаден в /etc/barman.d/ местоположение със следното съдържание

[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 е параметърът, който трябва да се конфигурира за барман да изпълнява поточно архивиране
backup_method трябва да бъде конфигуриран на „postgres“, когато трябва да се направи поточно архивиране
streaming_archiver трябва да бъде конфигуриран на „включено“
slot_name=barman Този параметър трябва да бъде конфигуриран, когато имате нужда от барман да използва слотове за репликация. В този случай името на слота за репликация е барман

След като конфигурацията приключи, направете барманска проверка, за да се уверите, че поточно архивирането ще работи успешно.

#4 Проверете дали barman receive-wal работи добре

По принцип за първия barman receive-wal не работи веднага след промени в конфигурацията, може да възникне грешка и командата barman check може да покаже следното -

[[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

Когато стартирате barman receive-wal, може да увисне. За да накара приемника да работи правилно за първи път, трябва да се изпълни командата по-долу.

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

Сега направете отново барманска проверка, вече трябва да е добре.

[[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

Ако можете да видите, състоянието на receivexlog показва OK. Това е един от проблемите, с които се сблъсках.

#5 Проверете дали барманът е готов да извършва архивиране

[[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 Проверете състоянието на поточно предаване с помощта на барман

[[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)

Горното състояние означава, че барманът е готов да извърши поточно архивиране. Извършете архивирането, както е показано по-долу -

[[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

Централизирани и каталогизирани архиви

Много е полезен за среди, работещи с множество бази данни на множество сървъри в мрежова среда. Това е една от изключителните черти на Барман. Работил съм в среда в реално време, в която трябваше да управлявам, администрирам 100 бази данни и винаги съм чувствал нуждата от централизирано архивиране на бази данни и поради това Oracle RMAN стана популярен за стратегията за архивиране на бази данни на Oracle и сега Барман изпълва това пространство за PostgreSQL. С Barman, DBA,s и DevOps инженерите могат да работят за изграждане на централизиран сървър за архивиране, в който се поддържат и валидират резервни копия на базата данни за всички бази данни.

Каталогизирани архиви, което означава, че barman поддържа централизирано хранилище, където се поддържат статусите на всички архиви. Можете да проверите наличните резервни копия за конкретна база данни, както е показано по-долу -

[[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

Правила за запазване на резервни копия

Правила за задържане може да се дефинира за архивиране на база данни. Архивните копия могат да бъдат превърнати в остарели след определен период, а остарелите архиви могат да бъдат изтривани от време на време.

В конфигурационния файл има опции, за да се уверите, че резервните копия се запазват и стават остарели, когато периодът на съхранение надвиши -

Първият параметър за конфигуриране е minimum_redundancy . Винаги конфигурирайте minimum_redundancy на>0, за да сте сигурни, че резервните копия няма да бъдат изтрити случайно.

Пример:minimum_redundancy =1

правила за_задържане параметърът ще определи колко дълго трябва да се съхраняват базовите резервни копия, за да се гарантира спазването на SLA за възстановяване при бедствие.
wal_retention_policy параметърът ще определи колко дълго трябва да се съхраняват резервните копия на wal. Това гарантира, че очакваното RPO е изпълнено.

Съществуващите политики за задържане и съкращаване за сървър на база данни могат да бъдат проверени с помощта на командата barman check, както следва

[[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

Паралелно архивиране и възстановяване може да се извърши чрез използване на множество процесори, което наистина прави архивирането и възстановяването завършено по-бързо. Тази функция е полезна за много големи бази данни с размери до TeraBytes.

За да изпълнявате паралелно архивиране, добавете следната опция в конфигурационния файл на сървъра на база данни (който е /etc/barman.d/pgdb.conf файл)-

parallel_jobs = 1

Мога да завърша, като кажа, че barman е инструмент от корпоративен клас, който потенциално може да помогне на администраторите на база данни да разработят ефективна стратегия за възстановяване след бедствие.

Свързани ресурси ClusterControl за PostgreSQLLНаучете повече Използване на pg_dump и pg_dumpall за архивиране на PostgreSQLПрочетете блога Водещи инструменти за архивиране за PostgreSQLПрочетете блога Станете PostgreSQL DBA – логически и физически резервни копия на PostgreSQL Прочетете блога