🥇Знайомство з 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

Заходимо до web-інтерфейсу Minio http://ip-адрес-сервера-minio:9000 та створюємо бакет (наприклад, pg-backups).

Сервер БД

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

У кого не RPM-based система використовуйте офіційну інструкцію із встановлення.

Разом з бінарником wal-g в rpm є скрипти, які імпортують змінні з файлу /etc/wal-gd/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-gd/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 — кількість кроків, на які максимально віддалена від base-бекапу дельта-бекап, та вказуєте політику дельта-копії. Або ви робите копію з останньої існуючої дельти, або робите дельту від початкового повного бекапу. Це потрібно на той випадок, коли у вас у базі даних завжди змінюється одна і та ж складова БД, одні й ті самі дані постійно змінюються.

Встановлюємо БД.

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

Дивимося записи в таблиці в бд

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

Backup extraction complete.

Додаємо recovery.conf до папки /var/lib/pgsql/9.6/data з наступним вмістом.

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

Запускаємо PostgreSQL. PostgreSQL запустить процес recovery з архівних 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 = '/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 запустить процес recovery з архівних 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 МБ в формате 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 МБ занимает полный бекап

LZMA

После генерации 1ГБ данных
338413694       s3://pg-backups/wal_005/
338 мб логов в формате lzma

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

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

270 мб занимает полный бекап в формате lzma

Бротлі

После генерации 1ГБ данных
459229886       s3://pg-backups/wal_005/
459 мб логов в формате brotli

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

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

312 мб занимает полный бекап в формате brotli

Порівняння результатів на графіку.