Най-добрите инструменти за архивиране за PostgreSQL

PostgreSQL има репутацията на стабилен от самото си начало и през годините е натрупал набор от впечатляващи функции. Въпреки това спокойствието, че вашите данни на диска са съвместими с ACID — ако не са допълнени от еквивалентна добре обмислена стратегия за архивиране — може лесно да бъде разбито.

Резервни типове

Преди да се потопим в наличните инструменти, нека разгледаме наличните типове архивиране на PostgreSQL и какви са техните характеристики:

SQL дъмпове (или логически)

Не блокира читатели или писатели.
Насочени към малки набори от данни поради отрицателното въздействие върху натоварването на системата и дългото време, необходимо както за операции по архивиране, така и за възстановяване. Производителността може да се повиши с флага –no-sync, но вижте справочната страница за рисковете, свързани с деактивирането на изчакването за запис.
Изисква се АНАЛИЗ след възстановяване, за да се оптимизира статистиката.
Глобални обекти като роли и пространства за таблици могат да бъдат архивирани само с помощта на помощната програма pg_dumpall. Имайте предвид, че директориите на пространството за таблици трябва да бъдат създадени ръчно, преди да започнете възстановяването.
Поддържа паралелизъм за сметка на повишеното натоварване на системата. Прочетете man pg_dump за неговите предупреждения и специални изисквания, напр. синхронизирани моментни снимки.
Дъмповете могат да се зареждат в по-нови версии на PostgreSQL или дори в друга машинна архитектура, но не е гарантирано, че са обратно съвместими между основните версии, така че може да се наложи ръчно редактиране на дъмп файла.

Файлова система (или физическа)

Изисква базата данни да бъде изключена.
По-бързо от логическите архиви.
Включва клъстерни данни.
Може да се възстанови само на същата основна версия на PostgreSQL.

Непрекъснато архивиране (или Point In Time Recovery или PITR)

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

Моментни снимки

Изисква поддръжка на операционна система — например LVM работи доста добре, което се потвърждава и от NetBackup за PostgreSQL Agent.
Подходящ за приложения, при които и директорията с данни, и базата данни трябва да са синхронизирани, напр. LAMP приложения, при условие че двете моментни снимки са синхронизирани.
Не се препоръчва, когато файловете на базата данни се съхраняват в множество файлови системи (трябва да направи моментна снимка на всички файлови системи едновременно).

Облак

Всички доставчици на облак внедряват архиви в своите PostgreSQL предложения. Логическите архиви могат да се извършват както обикновено, докато физическите архиви и PITR са достъпни чрез предложенията за облачни услуги, тъй като достъпът до хранилището на данни не е наличен (вижте например Amazon Aurora за PostgreSQL). Следователно архивирането на PostgreSQL в облака ще трябва да бъде тема за друг блог.

Агентна база

Изисква агент, инсталиран на целите.
Може да прави резервни копия на ниво блок, напр. COMMVAULT (инсталирането се поддържа само в Windows).

Функции

Докато PostgreSQL предоставя предварително инструментите, необходими за извършване на логически, физически и PITR архиви, специализираните приложения за архивиране разчитат на собствените инструменти на PostgreSQL и операционната система, за да задоволят необходимостта от прилагане на стратегия за архивиране, която се отнася до следните точки:

автоматизация
честота
период на задържане
целостта
лесна употреба

Освен това инструментите за архивиране на PostgreSQL се опитват да предоставят функции, общи за общите инструменти за архивиране, като например:

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

Настройка на лаборатория

За това упражнение настроих хост за команди и контрол, където ще инсталирам инструментите за архивиране, който също работи с два екземпляра на PostgreSQL — 9.6 и 10 — инсталирани от хранилища на PGDG:

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres  4535     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres  4538  4535  \_ postgres: logger process
postgres  4540  4535  \_ postgres: checkpointer process
postgres  4541  4535  \_ postgres: writer process
postgres  4542  4535  \_ postgres: wal writer process
postgres  4543  4535  \_ postgres: autovacuum launcher process
postgres  4544  4535  \_ postgres: stats collector process
postgres  4545  4535  \_ postgres: bgworker: logical replication launcher
postgres  4481     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres  4483  4481  \_ postgres: logger process
postgres  4485  4481  \_ postgres: checkpointer process
postgres  4486  4481  \_ postgres: writer process
postgres  4487  4481  \_ postgres: wal writer process
postgres  4488  4481  \_ postgres: autovacuum launcher process
postgres  4489  4481  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :543
tcp   0  0  127.0.0.1:5432  0.0.0.0:*  LISTEN  26  79972  4481/postmaster
tcp   0  0  127.0.0.1:5433  0.0.0.0:*  LISTEN  26  81801  4535/postmaster
tcp6  0  0  ::1:5432        :::*       LISTEN  26  79971  4481/postmaster
tcp6  0  0  ::1:5433        :::*       LISTEN  26  81800  4535/postmaster

Също така настроих две отдалечени екземпляра на PostgreSQL, работещи със същите версии 9.6 и съответно 10:

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10972     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres 10975 10972  \_ postgres: logger process
postgres 10977 10972  \_ postgres: checkpointer process
postgres 10978 10972  \_ postgres: writer process
postgres 10979 10972  \_ postgres: wal writer process
postgres 10980 10972  \_ postgres: autovacuum launcher process
postgres 10981 10972  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34864  10972/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34865  10972/postmaster


[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10829     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres 10831 10829  \_ postgres: logger process
postgres 10833 10829  \_ postgres: checkpointer process
postgres 10834 10829  \_ postgres: writer process
postgres 10835 10829  \_ postgres: wal writer process
postgres 10836 10829  \_ postgres: autovacuum launcher process
postgres 10837 10829  \_ postgres: stats collector process
postgres 10838 10829  \_ postgres: bgworker: logical replication launcher

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34242  10829/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34243  10829/postmaster

След това използвайте pgbench, за да създадете набор от данни:

pgbench=# \dt+
                          List of relations
 Schema |       Name       | Type  |  Owner   |  Size   | Description
--------+------------------+-------+----------+---------+-------------
 public | pgbench_accounts | table | postgres | 128 MB  |
 public | pgbench_branches | table | postgres | 40 kB   |
 public | pgbench_history  | table | postgres | 0 bytes |
 public | pgbench_tellers  | table | postgres | 40 kB   |
(4 rows)

Инструменти

Списък с често срещани инструменти за архивиране може да бъде намерен в секцията за архивиране на PostgreSQL Wiki. Допълних списъка с продукти, на които се натъкнах през годините, и от скорошно търсене в Интернет.

Аманда

Amanda е базирана на агент, с отворен код и поддържа PostgreSQL от кутията чрез ampgsql API. Към момента на писането, версията 3.5.1 не поддържа пространства за таблици (вижте man ampgsql).

Zmanda предоставя корпоративна версия, която също е с отворен код, но не е достъпна директно за изтегляне като пробна версия.

Amanda изисква специален хост за архивиране, тъй като пакетите на сървъра и клиента се изключват един друг:

[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_client-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_server
[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_server-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_client

Следвайте ръководството за основно конфигуриране, за да настроите сървъра и клиента, след което конфигурирайте PostgreSQL API.

Ето git diff от моята лаборатория:

Сървър:

увеличете пространството за архивиране на сървъра:

--- a/etc/amanda/omiday/amanda.conf
				+++ b/etc/amanda/omiday/amanda.conf
				@@ -13,7 +13,7 @@ amrecover_changer "changer"

				tapetype "TEST-TAPE"
				define tapetype TEST-TAPE {
				1.  length 100 mbytes
				2.  length 500 mbytes
					filemark 4 kbytes
				}

дефинирайте целта на PostgreSQL (и деактивирайте примерното архивиране):

--- a/etc/amanda/omiday/disklist
+++ b/etc/amanda/omiday/disklist
@@ -1,3 +1,2 @@
-localhost /etc simple-gnutar-local
+#localhost /etc simple-gnutar-local
+10.1.9.243 /var/lib/pgsql/9.6/data dt_ampgsql

Клиент:

конфигурация:

--- /dev/null
+++ b/etc/amanda/omiday/amanda-client.conf
@@ -0,0 +1,5 @@
+property "PG-DATADIR" "/var/lib/pgsql/9.6/data"
+property "PG-ARCHIVEDIR" "/var/lib/pgsql/9.6/archive"
+property "PG-HOST" "/tmp"
+property "PG-USER" "amandabackup"
+property "PG-PASSFILE" "/etc/amanda/pg_passfile"

файл за удостоверяване:

--- /dev/null
+++ b/etc/amanda/pg_passfile
@@ -0,0 +1 @@
+/tmp:*:*:amandabackup:pass

оторизира сървъра:

--- a/var/lib/amanda/.amandahosts
+++ b/var/lib/amanda/.amandahosts
@@ -1,2 +1,3 @@
localhost amandabackup amdump
localhost.localdomain amandabackup amdump
+10.1.9.231 amandabackup amdump

PostgreSQL удостоверяване:

--- a/var/lib/pgsql/9.6/data/pg_hba.conf
+++ b/var/lib/pgsql/9.6/data/pg_hba.conf
@@ -79,7 +79,8 @@
# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
-host    all             all             127.0.0.1/32            ident
+host    all             all             127.0.0.1/32            trust
+host    all             amandabackup    10.1.9.243/32           trust
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the

PostgreSQL конфигурация:

--- a/var/lib/pgsql/9.6/data/postgresql.conf
+++ b/var/lib/pgsql/9.6/data/postgresql.conf
@@ -178,6 +178,7 @@ dynamic_shared_memory_type = posix  # the default is the first option

#wal_level = minimal                   # minimal, replica, or logical
                                       # (change requires restart)
+wal_level = replica
#fsync = on                            # flush data to disk for crash safety
                                                # (turning this off can cause
                                                # unrecoverable data corruption)
@@ -215,10 +216,12 @@ dynamic_shared_memory_type = posix        # the default is the first option

#archive_mode = off            # enables archiving; off, on, or always
                              # (change requires restart)
+archive_mode = on
#archive_command = ''          # command to use to archive a logfile segment
                              # placeholders: %p = path of file to archive
                              #               %f = file name only
                              # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
+archive_command = 'test ! -f /var/lib/pgsql/9.6/archive/%f && cp %p /var/lib/pgsql/9.6/archive/%f'
#archive_timeout = 0           # force a logfile segment switch after this
                              # number of seconds; 0 disables

След като завършите горната конфигурация, стартирайте архивирането:

[[email protected] ~]$ amdump omiday

И проверете:

[[email protected] ~]$ amreport omiday
Hostname: cc
Org     : omiday
Config  : omiday
Date    : April 14, 2018

These dumps were to tape MyData01.
The next tape Amanda expects to use is: MyData02.


STATISTICS:
                        Total       Full      Incr.   Level:#
                        --------   --------   --------  --------
Estimate Time (hrs:min)     0:00
Run Time (hrs:min)          0:00
Dump Time (hrs:min)         0:00       0:00       0:00
Output Size (meg)            0.1        0.0        0.1
Original Size (meg)         16.0        0.0       16.0
Avg Compressed Size (%)      0.5        --         0.5
DLEs Dumped                    1          0          1  1:1
Avg Dump Rate (k/s)         33.7        --        33.7

Tape Time (hrs:min)         0:00       0:00       0:00
Tape Size (meg)              0.1        0.0        0.1
Tape Used (%)                0.0        0.0        0.0
DLEs Taped                     1          0          1  1:1
Parts Taped                    1          0          1  1:1
Avg Tp Write Rate (k/s)    830.0        --       830.0


USAGE BY TAPE:
Label                 Time         Size      %  DLEs Parts
MyData01              0:00          83K    0.0     1     1


NOTES:
planner: tapecycle (3) <= runspercycle (3)
planner: Last full dump of 10.1.9.243:/var/lib/pgsql/9.6/data on tape MyData04 overwritten in 3 runs.
taper: tape MyData01 kb 83 fm 1 [OK]


DUMP SUMMARY:
                                                               DUMPER STATS   TAPER STATS
HOSTNAME     DISK                    L ORIG-KB  OUT-KB  COMP%  MMM:SS   KB/s MMM:SS   KB/s
-------------------------------------- ---------------------- -------------- -------------
10.1.9.243   /var/lib/pgsql/9.6/data 1   16416      83    0.5    0:02   33.7   0:00  830.0

(brought to you by Amanda version 3.5.1)

Възстановяването от резервно копие включва повече ръчни стъпки, както е обяснено в раздела за възстановяване.

Според често задаваните въпроси на Amanda Enterprise следното подобрение ще се приложи към нашия пример за PostgreSQL:

конзола за управление за автоматизиране на архивиране, правила за задържане и графици
резервно копие в Amazon S3 облачно хранилище

Барман

Barman е решение за възстановяване след бедствие за PostgreSQL, поддържано от 2ndQuadrant. Той е проектиран да управлява архиви за множество бази данни и има възможност за възстановяване до предишен момент от време с помощта на функцията PITR на PostgreSQL.

Характеристики на Barman с един поглед:

работава с множество цели
поддръжка за различни версии на PostgreSQL
нулева загуба на данни
поточно предаване и/или стандартно архивиране на WALs
локално или отдалечено възстановяване
опростено възстановяване в даден момент

Както е отбелязано в ръководството на Barman, поддръжката за инкрементално архивиране, паралелни задания, дедупликация на данни и компресиране на мрежата е достъпна само при използване на опцията rsync. Също така, поточно предаване на WAL от режим на готовност с помощта на командата archive_command в момента не се поддържа.

След като изпълним инструкциите в ръководството за настройка на средата, можем да проверим:

-bash-4.2$ barman list-server
db1 - master
db2 - replica

-bash-4.2$ barman check db1
Server db1:
      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 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: OK
      archiver errors: OK

-bash-4.2$ barman check db2
Server db2:
      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 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: OK
      archiver errors: OK

Всичко е наред, така че можем да тестваме, като архивираме двата хоста:

-bash-4.2$ barman backup db1
Starting backup using postgres method for server db1 in /var/lib/barman/db1/base/20180414T091155
Backup start at LSN: 0/240001B0 (000000010000000000000024, 000001B0)
Starting backup copy via pg_basebackup for 20180414T091155
Copy done (time: 2 seconds)
Finalising the backup.
This is the first backup for server db1
WAL segments preceding the current backup have been found:
      000000010000000000000023 from server db1 has been removed
Backup size: 201.9 MiB
Backup end at LSN: 0/26000000 (000000010000000000000025, 00000000)
Backup completed (start time: 2018-04-14 09:11:55.783708, elapsed time: 2 seconds)
Processing xlog segments from file archival for db1
      000000010000000000000023
      000000010000000000000024
      000000010000000000000025.00000028.backup
Processing xlog segments from streaming for db1
      000000010000000000000024

-bash-4.2$ barman backup db2
Starting backup using postgres method for server db2 in /var/lib/barman/db2/base/20180414T091225
Backup start at LSN: 0/B0000D0 (00000001000000000000000B, 000000D0)
Starting backup copy via pg_basebackup for 20180414T091225
Copy done (time: 3 seconds)
Finalising the backup.
This is the first backup for server db2
WAL segments preceding the current backup have been found:
      000000010000000000000009 from server db2 has been removed
      00000001000000000000000A from server db2 has been removed
Backup size: 196.8 MiB
Backup end at LSN: 0/D000000 (00000001000000000000000C, 00000000)
Backup completed (start time: 2018-04-14 09:12:25.619005, elapsed time: 3 seconds)
Processing xlog segments from file archival for db2
      00000001000000000000000B
      00000001000000000000000C.00000028.backup
Processing xlog segments from streaming for db2
      00000001000000000000000B

Избройте резервния каталог:

-bash-4.2$ barman list-backup all
db1 20180414T091155 - Sat Apr 14 09:11:58 2018 - Size: 217.9 MiB - WAL Size: 0 B
db2 20180414T091225 - Sat Apr 14 09:12:28 2018 - Size: 212.8 MiB - WAL Size: 0 B

Показване на съдържанието за конкретен архив:

-bash-4.2$ barman list-files db1 20180414T091155 | head
/var/lib/barman/db1/base/20180414T091155/backup.info
/var/lib/barman/db1/base/20180414T091155/data/backup_label
/var/lib/barman/db1/base/20180414T091155/data/PG_VERSION
/var/lib/barman/db1/base/20180414T091155/data/postgresql.auto.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_ident.conf
/var/lib/barman/db1/base/20180414T091155/data/postgresql.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_hba.conf

Когато Barman е конфигуриран за синхронно поточно предаване на WAL, можем да проверим състоянието на репликация:

-bash-4.2$ barman replication-status db1
Status of streaming clients for server 'db1':
Current LSN on master: 0/26000528
Number of streaming clients: 1

1. Async WAL streamer
   Application name: barman_receive_wal
   Sync stage      : 3/3 Remote write
   Communication   : TCP/IP
   IP Address      : 10.1.9.231 / Port: 37278 / Host: -
   User name       : streaming_barman
   Current state   : streaming (async)
   Replication slot: barman
   WAL sender PID  : 2046
   Started at      : 2018-04-14 09:04:03.019323+00:00
   Sent LSN   : 0/26000528 (diff: 0 B)
   Write LSN  : 0/26000528 (diff: 0 B)
   Flush LSN  : 0/26000000 (diff: -1.3 KiB)

Допълнителни подобрения могат да бъдат добавени с помощта на предоставените hook скриптове.

И накрая, за любителите на командния ред, Barman идва с пълно завършване на TAB.

Инструмент за архивиране и възстановяване на EDB (BART)

EDB BART е собствено приложение със затворен код, предоставено от EnterpriseDB. Той съчетава естественото архивиране на PostgreSQL на ниво файлова система и PITR в лесен за използване инструмент, предоставящ следните функции:

правила за задържане
инкрементално архивиране
пълни, горещи, физически резервни копия на множество Postgres Plus Advanced Server и сървъри на база данни PostgreSQL
Управление на архивиране и възстановяване на сървърите на базата данни на локални или отдалечени хостове
централизиран каталог за архивиране на данни
съхранявайте архивни данни в компресиран формат
проверка на контролната сума

Докато пробната версия за най-новата версия v2.1 може да бъде получена само чрез заявка за yum repo, статията за архивиране на данни стана лесно и ръководството за документация на продукта предлагат известна информация за любопитните да научат повече.

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

pgBackRest

pgBackRest внедрява пълно архивиране на системата, което не разчита на общите инструменти tar и rsync. Понастоящем се хоства и предоставя от CrunchyData под лиценз на MIT. Вижте Разпознаване за подробности относно произхода му.

Той предлага всички функции, които човек може да очаква от инструмент, ориентиран към PostgreSQL:

висока пропускателна способност за архивиране/възстановяване
пълно, инкрементално и диференциално архивиране
правила за задържане
Проверка на целостта на архивиране и възстановяване чрез контролни суми на файлове и интеграция с контролни суми на PostgreSQL страници.
възможност за възобновяване на архивиране
поточно компресиране и контролни суми
Поддръжка за съхранение в облак на Amazon S3
Шифроване

..и още много. Вижте страницата на проекта за подробности.

Инсталацията изисква 64-битова Linux/Unix система и е описана в ръководството за потребителя. Ръководството също така запознава читателя с основните концепции, много полезни за тези, които са нови за PostgreSQL или технологията за съхранение.

Въпреки че ръководството използва примери за команди за Debian/Ubuntu, pgBackRest е наличен в хранилището на PGDG yum и инсталаторът ще изтегли всички зависимости:

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

pgbackrest       x86_64  2.01-1.rhel7     pgdg10  36k

Installing       for     dependencies:
perl-DBD-Pg      x86_64  2.19.3-4.el7     base    195k
perl-DBI         x86_64  1.627-4.el7      base    802k
perl-Digest-SHA  x86_64  1:5.85-4.el7     base    58k
perl-JSON-PP     noarch  2.27202-2.el7    base    55k
perl-Net-Daemon  noarch  0.48-5.el7       base    51k
perl-PlRPC       noarch  0.2020-14.el7    base    36k
perl-XML-LibXML  x86_64  1:2.0018-5.el7   base    373k
perl-version     x86_64  3:0.99.07-2.el7  base    84k

Нека настроим два клъстера, pg96 и pg10, всеки от които има един възел:

контролен възел („хранилище“ в ръководството):

[[email protected] ~]# cat /etc/pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

[pg96]
pg1-path=/var/lib/pgsql/9.6/data
pg1-host=db1
pg1-host-user=postgres

[pg10]
pg1-path=/var/lib/pgsql/10/data
pg1-host=db2
pg1-host-user=postgres

клъстер №1:

[[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

[pg96]
pg1-path=/var/lib/pgsql/9.6/data

клъстер №2:

[[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

[pg10]
pg1-path=/var/lib/pgsql/10/data

След това стартирайте архивиране и покажете архивния каталог:

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
   status: ok

   db (current)
      wal archive min/max (9.6-1): 00000001000000000000003D / 00000001000000000000003D

      full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB
-bash-4.2$ pgbackrest --stanza=pg10 info
stanza: pg10
   status: ok

   db (current)
      wal archive min/max (10-1): 000000010000000000000012 / 000000010000000000000012

      full backup: 20180414-120810F
            timestamp start/stop: 2018-04-14 12:08:10 / 2018-04-14 12:08:38
            wal start/stop: 000000010000000000000012 / 000000010000000000000012
            database size: 180.5MB, backup size: 180.5MB
            repository size: 11.6MB, repository backup size: 11.6MB

pgBackRest поддържа паралелизиране на архивиране и възстановяване — следвайки примера в ръководството, ние поддържаме един процесор и след това актуализираме конфигурацията, за да използваме 2 процесора:

--- a/etc/pgbackrest.conf
+++ b/etc/pgbackrest.conf
@@ -2,6 +2,7 @@
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y
+process-max=2

[pg96]
pg1-host=db1

Резултатът:

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
    status: ok

    db (current)
        wal archive min/max (9.6-1): 00000001000000000000003D / 000000010000000000000041

        full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB

        incr backup: 20180414-120727F_20180414-121434I
            timestamp start/stop: 2018-04-14 12:14:34 / 2018-04-14 12:14:52
            wal start/stop: 00000001000000000000003F / 00000001000000000000003F
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 431B
            backup reference list: 20180414-120727F

        incr backup: 20180414-120727F_20180414-121853I
            timestamp start/stop: 2018-04-14 12:18:53 / 2018-04-14 12:19:08
            wal start/stop: 000000010000000000000041 / 000000010000000000000041
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 429B
            backup reference list: 20180414-120727F

С 2 процесора архивирането работи почти с 20% по-бързо, което може да направи голяма разлика, когато работите срещу голям набор от данни.

Заключение

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

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