ProHoster > Блог > Администриране > Запознаване с wal-g системата за резервно копиране на PostgreSQL

Запознаване с wal-g системата за резервно копиране на PostgreSQL

WAL-G — прост и ефективен инструмент за резервно копиране на PostgreSQL в облака. По основната си функционалност той е наследник на популярния инструмент WAL-E, но пренаписан на Go. Но в WAL-G има една важна нова функция — делта-резервни копия. Делта-резервните копия WAL-G съхраняват страниците на файловете, които са се променили от предишната версия на резервното копие. В WAL-G са реализирани доста технологии за паралелизиране на резервните копия. WAL-G работи много по-бързо от WAL-E.

Подробности за работата на wal-g можете да прочетете в статията: Ускоряване на резервното копие. Лекция на Яндекс

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

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

За тестове на wal-g е необходим един сървър PostgreSQL, а като заместител на S3 се използва Minio.

Сървър Minio

Инсталация на Minio

yum -y install yum-plugin-copr
yum copr enable -y lkiesow/minio
yum install -y minio

Коригираме AccessKey и SecretKey в /etc/minio/minio.conf

vi /etc/minio/minio.conf

Ако не планирате да използвате nginx пред Minio, трябва да промените

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Стартираме Minio

systemctl start minio

Влизаме в уеб интерфейса на Minio http://ip-адрес-на-сървъра-minio:9000 и създаваме бакет (например, pg-backups).

Сървър на БД

WAL-G в rpm събира аз (Антон Пацев). Github, Fedora COPR.

За тези, които нямат RPM-базирана система, използвайте официалната инструкцията пътеводител за инсталация.

Заедно с бинарния файл wal-g в rpm присъстват скриптове, които импортират променливите от файла /etc/wal-g.d/server-s3.conf.

backup-fetch.sh
backup-list.sh
backup-push.sh
wal-fetch.sh
wal-g-run.sh
wal-push.sh

Инсталираме wal-g.

yum -y install yum-plugin-copr
yum copr enable -y antonpatsev/wal-g
yum install -y wal-g

Проверяваме версията на wal-g.

wal-g --version
wal-g version v0.2.14

Редактирайте /etc/wal-g.d/server-s3.conf по свои нужди.

Файловете за конфигурация и файловете с данни, използвани от клъстера на базата данни, традиционно се съхраняват заедно в каталога на данните на клъстера, който обикновено наричат PGDATA

#!/bin/bash

export PG_VER="9.6"

export WALE_S3_PREFIX="s3://pg-backups" # бакет, который мы создали в S3
export AWS_ACCESS_KEY_ID="xxxx" # AccessKey из /etc/minio/minio.conf 
export AWS_ENDPOINT="http://ip-адрес-сервера-minio:9000"
export AWS_S3_FORCE_PATH_STYLE="true"
export AWS_SECRET_ACCESS_KEY="yyyy" # SecretKey из /etc/minio/minio.conf

export PGDATA=/var/lib/pgsql/$PG_VER/data/
export PGHOST=/var/run/postgresql/.s.PGSQL.5432 # Сокет для подключения к PostgreSQL

export WALG_UPLOAD_CONCURRENCY=2 # Кол-во потоков для закачки 
export WALG_DOWNLOAD_CONCURRENCY=2 # Кол-во потоков для скачивания
export WALG_UPLOAD_DISK_CONCURRENCY=2 # Кол-во потоков на диске для закачки
export WALG_DELTA_MAX_STEPS=7
export WALG_COMPRESSION_METHOD=brotli # Какой метод сжатия использовать.

Когато настройвате WAL-G, вие определяте WALG_DELTA_MAX_STEPS — броя на стъпките, на които максимално може да се отдалечи дельта-бэкап от базовия бэкап, и определяте политиката за дельта-копието. Или правите копие с последната съществуваща дельта, или правите дельта от първоначалния пълен бэкап. Това е нужно за случая, когато в базата данни постоянно се променя един и същ елемент, едни и същи данни постоянно се променят.

Настройваме БД.

yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install -y postgresql96 postgresql96-server mc

Инициализираме бд.

/usr/pgsql-9.6/bin/postgresql96-setup initdb
Initializing database ... OK

Ако тествате на 1 сървър, трябва да пренастроите параметъра wal_level на archive за PostgreSQL по-малко от версия 10, и replica за PostgreSQL 10 версия и по-стари.

wal_level = archive

Ще правим архивиране на WAL архивите на всеки 60 секунди с помощта на самия PostgreSQL. На продукция ще имате друга стойност archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # На всеки 60 секунди ще се изпълнява командата archive_command.

Стартираме PostgreSQL

systemctl start postgresql-9.6

В отделен конзол виждаме логовете на PostgreSQL за грешки: (postgresql-Wed.log сменяте с текущия).

tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

Влизаме в psql.

su - postgres
psql

В psql създаваме БД.

Създаваме таблица в бд test1.

create database test1;

Превключваме се на бд test.

postgres=# c test1;

Създаваме таблица indexing_table.

test1=# CREATE TABLE indexing_table(created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());

Добавяне на данни.

Стартираме вмъкването на данни. Чакаме 10-20 минути.

#!/bin/bash
# postgres
while true; do
psql -U postgres -d test1 -c "INSERT INTO indexing_table(created_at) VALUES (CURRENT_TIMESTAMP);"
sleep 60;
done

Задължително правим пълен бэкап.

su - postgres
/usr/local/bin/backup-push.sh

Виждаме записите в таблицата в бд test1

select * from indexing_table;
2020-01-29 09:41:25.226198+
2020-01-29 09:42:25.336989+
2020-01-29 09:43:25.356069+
2020-01-29 09:44:25.37381+
2020-01-29 09:45:25.392944+
2020-01-29 09:46:25.412327+
2020-01-29 09:47:25.432564+
2020-01-29 09:48:25.451985+
2020-01-29 09:49:25.472653+
2020-01-29 09:50:25.491974+
2020-01-29 09:51:25.510178+

Строката е текущото време.

Виждаме списъка с пълни бэкапи.

/usr/local/bin/backup-list.sh

Тестване на възстановяване

Пълно възстановяване с прилагане на всички налични WAL.

Спираме Postgresql.

Изтриваме всичко от папката /var/lib/pgsql/9.6/data.

Стартираме скрипта /usr/local/bin/backup-fetch.sh от потребителя postgres.

su - postgres
/usr/local/bin/backup-fetch.sh

Завършено извличане на резервно копие.

Добавяме recovery.conf в папката /var/lib/pgsql/9.6/data с следното съдържание.

restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'

Стартираме PostgreSQL. PostgreSQL ще стартира процеса на възстановяване от архивните WAL, и само после базата ще се отвори.

systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

Възстановяване на определено време.

Ако искаме да възстановим базата до определен момент, в recovery.conf добавяме параметъра recovery_target_time — указваме до кое време да възстановим базата.

restore_command = 'fi/ usr/ local/ bin/ wal-fetch.sh "%f" "%p"' 
recovery_target_time = '2020-01-29 09:46:25'

След възстановяването поглеждаме таблицата indexing_table

 2020-01-29 09:41:25.226198+00
 2020-01-29 09:42:25.336989+00
 2020-01-29 09:43:25.356069+00
 2020-01-29 09:44:25.37381+00
 2020-01-29 09:45:25.392944+00

Стартираме PostgreSQL. PostgreSQL ще стартира процеса на възстановяване от архивните WAL, и само после базата ще се отвори.

systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

Тестване

Генерирайте 1GB база данни, както е описано тук https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Искаме размера на бъкет след генерирането на 1GB данни.

postgres=# SELECT pg_size_pretty(pg_database_size('test1'));
pg_size_pretty
----------------
1003 MB

s4cmd — безплатен инструмент за команден ред за работа с данни, разположени в хранилището на Amazon S3. Утилитата е написана на Python, което позволява да се използва както в Windows, така и в Linux.

Инсталираме s4cmd

pip install s4cmd

LZ4

s4cmd --endpoint-url=http://ip-адрес-сервера-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822       s3://pg-backups/wal_005/
840 MB в lz4 формат само за WAL логовете

Цялостен бекъп с lz4 - 1GB данни
time backup_push.sh
real 0m18.582s

Размер на S3 бъкета след пълния бекъп

581480085       s3://pg-backups/basebackups_005/
842374424   s3://pg-backups/wal_005
581 MB заема целия бекъп

LZMA

След генерирането на 1GB данни
338413694       s3://pg-backups/wal_005/
338 MB лога в lzma формат

Време за генериране на целия бекъп
time backup_push.sh
real    5m25.054s

Размер на бъкета в S3
270310495       s3://pg-backups/basebackups_005/
433485092   s3://pg-backups/wal_005/

270 MB заема целия бекъп в lzma формат

Brotli

След генерирането на 1GB данни
459229886       s3://pg-backups/wal_005/
459 MB лога в brotli формат

Време за генериране на целия бекъп
real    0m23.408s

Размер на бъкета в S3
312960942       s3://pg-backups/basebackups_005/
459309262   s3://pg-backups/wal_005/

312 MB заема целия бекъп в brotli формат

Сравнение на резултатите на графиката.

Запознаване с wal-g системата за резервно копиране на PostgreSQL

Както виждаме, Brotli е сравним по размер с LZMA, но бекъпът се извършва за времето на LZ4.

Чат на рускоговорещата общност на PostgreSQL: https://t.me/pgsql

Моля, поставете звезда в Github, ако използвате wal-g

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster