Barman Cloud – Част 1:Архив на WAL

Преамбюл

Колко настоящи потребители на Barman са помислили за запазване на резервни копия в отдалечена дестинация в облака? Колко са мислили да вземат този архив директно от самия PostgreSQL сървър?

Е, от Barman 2.10 това вече е възможно!
Как?
Нека открием това заедно в следващите статии.

Изисквания

Следните две статии са предназначени да бъдат практическо въведение в новия barman-cloud-wal-archive и barman-cloud-backup инструменти, добавени в barman-cli пакет.
Първата част ще обхваща barman-cloud-wal-archive команда, докато втората ще обхване barman-cloud-backup команда.
Читателите се нуждаят от основни познания за PostgreSQL WAL архивиране и методи за архивиране и Barman. Също така се препоръчва да сте наясно с облачните технологии за решения за съхранение като Amazon S3.

WAL архив

Barman е действал като отдалечен WAL архив в продължение на много години, а пакетът Barman CLI е проектиран да разшири надеждността и стабилността на архивирането от страна на PostgreSQL. Всъщност barman-cli предоставя скриптове като barman-wal-restore позволявайки на възел в режим на готовност да възстановява интелигентно и безопасно WAL файлове от архив на Barman чрез restore_command параметър в postgresql.auto.conf файл (или recovery.conf файл до PostgreSQL 12) и barman-wal-archive да архивирате WAL файлове от главен възел към Barman чрез archive_command параметър, конфигуриран в postgresql.conf файл.

Облачен WAL архив

Благодарение на отзивите на потребителите, разработчиците на Barman въведоха два нови инструмента във версия 2.10 :

barman-cloud-wal-archive
barman-cloud-backup

Версия 2.11 ще включва два допълнителни инструмента за възстановяване, наречени barman-cloud-wal-restore и barman-cloud-restore .
Тази публикация е изцяло посветена на barman-cloud-wal-archive , който може да съхранява WAL файлове в облака, позволявайки многостепенно архивиране с Barman и разширяване на политиката за запазване на архиви.
Наистина, barman-cloud-wal-archive може да се използва като hook-скрипт, конфигуриращ pre_archive_retry_script параметър в Barman, за да копирате WAL файлове в конфигурираното облачно хранилище, което увеличава излишъка на архива и прави възможно избора на по-дълга политика на задържане от тази на Barman.

Това не е всичко!

barman-cloud-wal-archive може да замени barman-wal-archive команда в archive_command параметър, за да архивирате директно WAL файлове в облака, вместо да ги копирате в сървъра на Barman. По този начин дори PostgreSQL клъстер, който няма отделен специален сървър за архивиране, може да разчита на услуга за отдалечено съхранение за архивиране на WAL файлове.

Как работи?

Следните инструкции са само за инсталиране и конфигуриране на barman-cloud-wal-archive като archive_command в PostgreSQL.
Първо решете къде да архивирате WAL файлове. В тази статия ще използваме Amazon S3, който към момента на писане е единствената поддържана технология. Въпреки че други технологии, които поддържат API, подобен на S3 (Google Cloud, DigitalOcean, Microsoft Azure и др.), могат да работят с библиотека boto3, те все още не са тествани.

Изисквания

barman-cli 2.10 (или по-нова версия)
Amazon AWS акаунт
awscli
S3 кофа
Екземпляр на PostgreSQL

В тази статия ще тестваме Barman CLI във виртуална машина с Debian Buster и PostgreSQL 12 който вече работи и работи.

Инсталиране

Инсталирайте публичното хранилище 2ndQuadrant

Инсталирайте пакета barman-cli

[email protected]:~# apt [email protected]:~# apt install barman-cli

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

[email protected]:~# apt install awscli

Конфигуриране и настройка

Нека да прочетем ръководството:

[email protected]:~$ man barman-cloud-wal-archive[...]СИНОПСИС barman-cloud-wal-archive [ОПЦИИ] DESTINATION_URL SERVER_NAME WAL_PATH[...]POSITIONAL ARGUMENTS DESTINATION_URL URL  на облака дестинация, като например кофа в AWS S3. Например:s3://BUCKET_NAME/path/to/folder (където BUCKET_NAME е кофата, която сте създали в AWS). SERVER_NAME името на сървъра, както е конфигурирано в Barman. WAL_PATH стойността на ключовата дума `%p' (според `archive_command').[...]

Така че, за да го използваме правилно, просто трябва да конфигурираме идентификационните данни на AWS с awscli инструмент като postgres потребител, копирайки ключа за достъп и секретния ключ, създадени преди това в секцията IAM в конзолата на AWS:

[email protected]:~$ aws configure --profile barman-cloudAWS Идентификатор на ключ за достъп [Няма]:AKI******************** AWS секретен ключ за достъп [Няма ]:**************************************** Име на региона по подразбиране [Няма]:eu -west-1Изходен формат по подразбиране [Няма]:json

Уверете се, че имате налична S3 кофа на AWS. Избрах да го нарека barman-s3-test за да стане ясно.
Сега трябва да можем да тестваме barman-cloud-wal-archive команда:

[email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/00000001000000000000000 @sqldat.com:~$ echo $?0

Състоянието на изход потвърждава, че командата е успешна. Вече можем да добавим следния ред в долната част на конфигурационния файл на PostgreSQL и да рестартираме екземпляра:
archive_mode = on

[email protected]:~# systemctl рестартиране [email protected]

Тъй като нашите данни ще бъдат копирани в отдалечено хранилище, извън нашия контрол, важно е да ги съхраняваме компресирани и криптирани . barman-cloud-wal-archive командата поддържа два различни метода за компресиране:

[email protected]:~$ barman-cloud-wal-archive --help[...] -z, --gzip            gzip-компресирайте WAL, докато качвате в облака -j, --bzip2           bzip2- компресирайте WAL по време на качване в облака -e КРИФИРАНЕ, --encryption КРИФИРАНЕ Разрешаване на криптиране от страна на сървъра за прехвърляне. Позволени стойности:'AES256', 'aws:kms'[...]

Опцията за криптиране просто ще информира S3 кофата кой метод да използва за съхраняване на криптирани данни. Криптираните данни не могат да бъдат прочетени от друг потребител на AWS, освен от собственика на кофата. Barman cloud не криптира нито един обект, преди да го изпрати до S3, той просто иска кофата да ги съхранява криптирани, ако S3 е бил правилно конфигуриран. Въпреки това, всички връзки към S3 се установяват сигурно чрез https .

Нека добавим следния ред в долната част на postgresql.conf файл:

archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'

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

[email protected]:~$ psql -c “SELECT pg_reload_conf()”

За да провери дали новата archive_command работи, PostgreSQL трябва да създаде WAL файлове, които да бъдат архивирани, следователно трябва да направим малко трафик с помощта на pgbench инструмент:

[email protected]:~$ createdb [email protected]:~$ pgbench -i -s10 pg_bench_db[някакъв неуместен изход тук][email protected]:~$ pgbench -c 10 -j 2 -T 30 pg_bench_dbstarting vacuum...end.transaction type:коефициент на мащабиране:10 режим на заявка:прост брой клиенти:10 брой нишки:2 продължителност:30 брой действително обработени транзакции:84501 закъснение2 =средно mstps5. 2815.224687 (включително установяване на връзки)tps =2815.427535 (с изключение на установяване на връзки)

В този момент трябва да видим WAL файлове, архивирани в S3 bucket. Нека го проверим, като изградим целевия път с името на сървъра и WAL дестинационната директория:

[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/

Нека погледнем вътре в директорията 0000000100000000:

[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/0000000100000000/2020-01-08 08:20:54 6 000 00 00 00 00 00 00 00 000 16020 0000 -01-08 08:21:00 293422 0000000100000000000002.BZ22020-01-08 08:21:06 3019300 0000000100000000000003.BZ22020-01-08 08:21:11 295648 .bz22020-01-08 08:21:21 299348 000000010000000000000006.bz22020-01-08 08:21:27 551249 000000010000000000000007.bz22020-01-08 08:21:33 976523 000000010000000000000008.bz22020-01-08 08:21:37 4542104 0000000100000000000009.bz22020-01-08 08:21:46 5052693 0000000100000000000000A.bz2.

Страхотно!

WAL файловете се компресират, преди да бъдат качени в кофата на S3 и се съхраняват криптирани, което ни спестява място (и пари) и повишава нивото на сигурност на нашите данни.

Заключения

barman-cloud-wal-archive командата е това, което потребителите са чакали дълго време.

Ако сте един от тези, които са използвали pre_archive_retry_script за да приложите персонализиран скрипт за качване на WAL файлове в S3 кофа, тогава това може да се използва като по-добър заместител, защото е разработен и поддържан от разработчиците на Barman и е тестван и доставян от системата за непрекъсната доставка на 2ndQuadrant.

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

В противен случай може да се използва, както направихме в тази статия, за архивиране на WAL файлове директно от сървъра на PostgreSQL. Въпреки че това премахва междинна стъпка, RPO се увеличава в сравнение с метода за поточно предаване, тъй като PostgreSQL ще архивира WAL файл само след като го затвори. Следователно, в случай на проблеми на възела PostgreSQL, можем да загубим някои промени. Когато е възможно, препоръчваме да приложите този метод заедно с поточно предаване към сървър на Barman, за да постигнете RPO=0 (със синхронно поточно предаване).

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

Ще се видим във втората част на статията.