Въведение в системата за архивиране на 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.

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

Минио сървър

Инсталиране на 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).

DB сървър

Сглобявам WAL-G в обороти (Антон Пацев). Github, Fedora COPR.

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

Заедно с двоичния файл 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 - броят стъпки, които делта архивирането е максимално спрямо базовото архивиране, и посочвате политиката за делта копиране. Или правите копие от последната съществуваща делта, или правите делта от оригиналния пълен архив. Това е необходимо в случай, че когато един и същ компонент на базата данни винаги се променя във вашата база данни, едни и същи данни се променят постоянно.

Инсталиране на базата данни.

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, за да архивирате за PostgreSQL под версия 10 и реплика за 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;

Преминете към теста на базата данни.

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_target_time към recovery.conf - посочваме в кое време да възстановим базата данни.

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 ще стартира процеса на възстановяване от архивирания WAL и едва тогава базата данни ще се отвори.

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

Тестване

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

Ние изискваме размера на кофата след генериране на 1 GB данни.

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

Brotli

После генерации 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

Сравнение на резултатите на диаграмата.

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

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

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

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