Как да използвате pgBackRest за архивиране на PostgreSQL и TimescaleDB

Вашите данни вероятно са най-ценните активи в компанията, така че трябва да имате план за възстановяване при бедствия (DRP), за да предотвратите загуба на данни в случай на авария или хардуерна повреда. Резервното копие е най-простата форма на DR. Може да не винаги е достатъчно да гарантира приемлива цел за точка на възстановяване (RPO), но е добър първи подход. Също така трябва да дефинирате цел за време за възстановяване (RTO) според изискванията на вашата компания. Има много начини за достигане на стойността на RTO, това зависи от целите на компанията.

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

Какво е pgBackRest?

Има различни видове архиви за бази данни:

Логически:Архивът се съхранява в четим от човека формат като SQL.
Физически:Архивът съдържа двоични данни.
Пълно/инкрементално/диференциално:Дефиницията на тези три типа архиви е имплицитна в името. Пълното архивиране е пълно копие на всички ваши данни. Инкременталното архивиране архивира само данните, които са се променили след предишното архивиране, а диференциалното архивиране съдържа само данните, които са се променили от последното изпълнено пълно архивиране. Инкременталното и диференциалното архивиране бяха въведени като начин за намаляване на времето и използването на дисково пространство, необходими за извършване на пълно архивиране.

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

Някои от най-важните функции на pgBackRest са:

Паралелно архивиране и възстановяване
Локална или отдалечена работа
Пълно, инкрементално и диференциално архивиране
Въртене на резервно копие и изтичане на архива
Проверка на целостта на архивиране
Резервно резюме
Delta Restore
Шифроване

Сега нека видим как можем да използваме pgBackRest за архивиране на нашите PostgreSQL и TimescaleDB бази данни.

Как да използвате pgBackRest

За този тест ще използваме CentOS 7 като ОС и PostgreSQL 11 като сървър на база данни. Ще приемем, че имате инсталирана база данни, ако не, можете да следвате тези връзки, за да разгърнете както PostgreSQL, така и TimescaleDB по лесен начин, като използвате ClusterControl.

Първо, трябва да инсталираме пакета pgbackrest.

$ yum install pgbackrest

pgBackRest може да се използва от командния ред или от конфигурационен файл, разположен по подразбиране в /etc/pgbackrest.conf на CentOS7. Този файл съдържа следните редове:

[global]
repo1-path=/var/lib/pgbackrest
#[main]
#pg1-path=/var/lib/pgsql/10/data

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

Ще добавим следните редове:

[testing]
pg1-path=/var/lib/pgsql/11/data

Уверете се, че сте добавили следната конфигурация във файла postgresql.conf (тези промени изискват рестартиране на услугата).

archive_mode = on
archive_command = 'pgbackrest --stanza=testing archive-push %p'
max_wal_senders = 3
wal_level = logical

Сега, нека направим основно резервно копие. Първо, трябва да създадем „строфа“, която дефинира конфигурацията за архивиране за конкретен PostgreSQL или TimescaleDB клъстер от база данни. Разделът за строфа трябва да дефинира пътя на клъстера на базата данни и хост/потребител, ако клъстерът на базата данни е отдалечен.

$ pgbackrest --stanza=testing --log-level-console=info stanza-create
2019-04-29 21:46:36.922 P00   INFO: stanza-create command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:46:37.475 P00   INFO: stanza-create command end: completed successfully (554ms)

След това можем да изпълним командата check, за да потвърдим конфигурацията.

$ pgbackrest --stanza=testing --log-level-console=info check
2019-04-29 21:51:09.893 P00   INFO: check command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:51:12.090 P00   INFO: WAL segment 000000010000000000000001 successfully stored in the archive at '/var/lib/pgbackrest/archive/testing/11-1/0000000100000000/000000010000000000000001-f29875cffe780f9e9d9debeb0b44d945a5165409.gz'
2019-04-29 21:51:12.090 P00   INFO: check command end: completed successfully (2197ms)

За да направите резервно копие, изпълнете следната команда:

$ pgbackrest --stanza=testing --type=full --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=full
WARN: option repo1-retention-full is not set, the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 15:43:21": backup begins after the next regular checkpoint completes
INFO: backup start archive = 000000010000000000000006, lsn = 0/6000028
WARN: aborted backup 20190429-215508F of same type exists, will be cleaned to remove invalid files and resumed
INFO: backup file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: full backup size = 31.8MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 000000010000000000000006, lsn = 0/6000130
INFO: new backup label = 20190429-215508F
INFO: backup command end: completed successfully (12810ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (10ms)

Сега архивирането приключи с изхода „завършен успешно“, така че нека да го възстановим. Ще спрем услугата postgresql-11.

$ service postgresql-11 stop
Redirecting to /bin/systemctl stop postgresql-11.service

И оставете директорията с данни празна.

$ rm -rf /var/lib/pgsql/11/data/*

Сега изпълнете следната команда:

$ pgbackrest --stanza=testing --log-level-stderr=info restore
INFO: restore command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
INFO: restore backup set 20190429-215508F
INFO: restore file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: write /var/lib/pgsql/11/data/recovery.conf
INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
INFO: restore command end: completed successfully (10819ms)

След това стартирайте услугата postgresql-11.

$ service postgresql-11 stop

И сега нашата база данни работи и работи.

$ psql -U app_user world
world=> select * from city limit 5;
 id |      name      | countrycode |   district    | population
----+----------------+-------------+---------------+------------
  1 | Kabul          | AFG         | Kabol         |    1780000
  2 | Qandahar       | AFG         | Qandahar      |     237500
  3 | Herat          | AFG         | Herat         |     186800
  4 | Mazar-e-Sharif | AFG         | Balkh         |     127800
  5 | Amsterdam      | NLD         | Noord-Holland |     731200
(5 rows)

Сега да видим как можем да направим диференциално резервно копие.

$ pgbackrest --stanza=testing --type=diff --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=diff
WARN: option repo1-retention-full is not set, the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: last backup label = 20190429-215508F, version = 2.13
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 21:22:58": backup begins after the next regular checkpoint completes
INFO: backup start archive = 00000002000000000000000B, lsn = 0/B000028
WARN: a timeline switch has occurred since the last backup, enabling delta checksum
INFO: backup file /var/lib/pgsql/11/data/base/16429/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/16429/2608 (448KB, 8%) checksum 53bd7995dc4d29226b1ad645995405e0a96a4a7b
. . .
INFO: diff backup size = 40.1MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 00000002000000000000000B, lsn = 0/B000130
INFO: new backup label = 20190429-215508F_20190430-212258D
INFO: backup command end: completed successfully (23982ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (14ms)

За по-сложни архиви можете да следвате ръководството за потребителя на pgBackRest.

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

Как да използвате pgBackRest в ClusterControl

От версия 1.7.2 ClusterControl добави поддръжка за pgBackRest за архивиране на PostgreSQL и TimescaleDB бази данни, така че нека видим как можем да го използваме от ClusterControl.

Създаване на резервно копие

За тази задача отидете на ClusterControl -> Изберете Cluster -> Backup -> Create Backup.

Можем да създадем ново архивиране или да конфигурираме планирано. За нашия пример ще създадем единично резервно копие незабавно.

Трябва да изберем един метод, сървъра, от който ще бъде взето архивирането и къде искаме да съхраняваме архива. Можем също да качим нашето резервно копие в облака (AWS, Google или Azure), като активираме съответния бутон.

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

„По време на първия опит за създаване на pgBackRest архивиране, ClusterControl ще конфигурира отново възела (разгръща и конфигурира pgBackRest) и след това възелът db трябва първо да бъде рестартиран.

Така че, моля, вземете го предвид при първия опит за архивиране.

След това указваме използването на компресия и нивото на компресия за нашия архив.

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

Стъпките са едни и същи за създаване на диференциал на инкрементално архивиране. Трябва само да изберем желания метод по време на създаването на резервно копие.

Възстановяване на резервно копие

След като архивирането приключи, можем да го възстановим с помощта на ClusterControl. За това в нашия раздел за архивиране (ClusterControl -> Изберете Cluster -> Backup) можем да изберем „Възстановяване на архива“ или директно „Възстановяване“ на архива, който искаме да възстановим.

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

Ако изберем опцията Възстановяване на възел, трябва да посочим главния възел, защото той е единственият за запис в клъстера.

Можем да наблюдаваме напредъка на нашето възстановяване от секцията Активност в нашия ClusterControl.

Автоматично потвърждаване на архивиране

Архивът не е резервно копие, ако не може да се възстанови. Проверката на архивиране е нещо, което обикновено се пренебрегва от мнозина. Нека видим как ClusterControl може да автоматизира проверката на резервните копия на PostgreSQL и TimescaleDB и да помогне за избягване на всякакви изненади.

В ClusterControl изберете своя клъстер и отидете в секцията „Архивиране“, след което изберете „Създаване на архивиране“.

Функцията за автоматично потвърждаване на архивиране е налична за планираните архиви. И така, нека изберем опцията „График за архивиране“.

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

В следващата стъпка можем да компресираме нашия архив и да активираме функцията „Проверка на архивиране“.

За да използваме тази функция, се нуждаем от специален хост (или VM), който не е част от клъстера.

ClusterControl ще инсталира софтуера и ще възстанови архива в този хост. След възстановяване можем да видим иконата за проверка в секцията за архивиране на ClusterControl.

Препоръки

Има и някои съвети, които можем да вземем предвид, когато създаваме резервни копия:

Съхранявайте архива на отдалечено място:Не трябва да съхраняваме архива на сървъра на базата данни. В случай на повреда на сървъра, можем да загубим базата данни и архива едновременно.
Запазете копие на най-новото архивно копие на сървъра на базата данни:Това може да е полезно за по-бързо възстановяване.
Използвайте инкрементални/диференциални архиви:За да намалите времето за възстановяване на резервно копие и използването на дисково пространство.
Архивиране на WAL:Ако трябва да възстановим база данни от последното архивиране, ако я възстановите само, ще загубите промените, откакто бе направено резервното копие до времето за възстановяване, но ако имаме WAL, можем да приложим промените и можем да използваме PITR.
Използвайте както логическо, така и физическо архивиране:И двете са необходими по различни причини, например, ако искаме да възстановим само една база данни/таблица, нямаме нужда от физическото архивиране, имаме нужда само от логическото архивиране и то ще бъдете дори по-бързи от възстановяването на целия сървър.
Вземете резервни копия от резервни възли (ако е възможно):За да избегнете допълнително натоварване на основния възел, е добра практика да вземете резервното копие от сървъра в режим на готовност.
Тествайте резервните си копия:Потвърждението, че архивирането е направено, не е достатъчно, за да се гарантира, че архивирането работи. Трябва да го възстановим на самостоятелен сървър и да го тестваме, за да избегнем изненада в случай на повреда.

Заключение

Както видяхме, pgBackRest е добър вариант за подобряване на нашата стратегия за архивиране. Той ви помага да защитите вашите данни и може да бъде полезно да достигнете до RTO, като намалите времето за престой в случай на повреда. Постепенното архивиране може да помогне за намаляване на времето и пространството за съхранение, използвани за процеса на архивиране. ClusterControl може да помогне за автоматизирането на процеса на архивиране на вашите PostgreSQL и TimescaleDB бази данни и, в случай на неуспех, да го възстановите с няколко щраквания.