🥇Seznámení se systémem zálohování wal-g pro PostgreSQL

WAL-G — jednoduchý a efektivní nástroj pro zálohování PostgreSQL do cloudu. V zásadě navazuje na populární nástroj WAL-E, ale je přepsán v Go. V WAL-G je však jedna důležitá nová funkce — delta zálohy. Delta zálohy WAL-G uchovávají stránky souborů, které se od předchozí verze zálohy změnily. WAL-G implementuje řadu technologií pro paralelizaci záloh. WAL-G funguje mnohem rychleji než WAL-E.

Podrobnosti o fungování wal-g si můžete přečíst v článku: Zrychlení zálohy. Přednáška od Yandexu

Protokol S3 se stal populárním pro ukládání dat. Jednou z výhod S3 je možnost přístupu přes API, což umožňuje flexibilní interakci se storage, včetně veřejného přístupu pro čtení, zatímco aktualizace informací ve storage probíhá pouze autorizovanými osobami.

Existuje několik otevřených i soukromých implementací storage, které fungují podle protokolu S3. Dnes se podíváme na populární řešení pro organizaci malých storage — Minio.

Pro testování wal-g postačí jeden server PostgreSQL, přičemž jako náhrada za S3 používáme Minio.

Server Minio

Instalace Minio

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

Upravujeme AccessKey a SecretKey v /etc/minio/minio.conf

vi /etc/minio/minio.conf

Pokud nebudete používat nginx před Minio, je potřeba změnit

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Spouštíme Minio

systemctl start minio

Přejdeme do webového rozhraní Minio http://ip-adresa-serveru-minio:9000 a vytvoříme bucket (například pg-backups).

Server DB

WAL-G v rpm sestavuji já (Anton Pacev). Github, Fedora COPR.

Pro ty, kteří nemají systém založený na RPM, použijte oficiální návod na instalaci.

Spolu s binárním souborem wal-g v rpm jsou přítomny skripty, které importují proměnné ze souboru /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

Instalujeme wal-g.

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

Kontrolujeme verzi wal-g.

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

Upravujeme /etc/wal-g.d/server-s3.conf podle vlastních potřeb.

Konfigurační soubory a datové soubory, které používá cluster databáze, se tradičně ukládají spolu v adresáři dat clusteru, což je obvykle nazýváno 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 # Какой метод сжатия использовать.

Při konfiguraci WAL-G nastavíte WALG_DELTA_MAX_STEPS — maximální počet kroků, o které se delta záloha může odchýlit od základní zálohy, a také určíte politiku delta kopie. Buď vytváříte kopii z poslední existující delty, nebo vytváříte deltovou zálohu z původní úplné zálohy. To je důležité v případě, kdy se ve vaší databázi neustále mění stejná část databáze, které se neustále mění stejná data.

Instalujeme databázi.

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

Inicializujeme databázi.

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

Pokud testujete na 1 serveru, musíte změnit parametr wal_level na archive pro PostgreSQL verzi nižší než 10, a na replica pro PostgreSQL verzi 10 a vyšší.

wal_level = archive

Zajišťujeme zálohování WAL archivů každých 60 sekund pomocí samotného PostgreSQL. Na produkčním prostředí budete mít jinou hodnotu archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Každých 60 sekund bude vykonána příkaz archive_command.

Spouštíme PostgreSQL

systemctl start postgresql-9.6

V samostatné konzoli sledujeme logy PostgreSQL na chyby: (postgresql-Wed.log změňte na aktuální).

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

Přihlašujeme se do psql.

su - postgres
psql

V psql vytváříme databázi.

Vytváříme tabulku v databázi test1.

create database test1;

Přepínáme se na databázi test.

postgres=# c test1;

Vytváříme tabulku indexing_table.

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

Přidání dat.

Spouštíme vkládání dat. Čekáme 10-20 minut.

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

Rozhodně děláme úplnou zálohu.

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

Sledujeme záznamy v tabulce v databázi 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+

Řádek to je aktuální čas.

Sledujeme seznam úplných záloh

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

Testování obnovy

Úplná obnova s aplikováním všech dostupných WAL.

Zastavujeme Postgresql.

Odstraňujeme všechno z adresáře /var/lib/pgsql/9.6/data.

Spouštíme skript /usr/local/bin/backup-fetch.sh od uživatele postgres.

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

Extrakce zálohy dokončena.

Přidáváme recovery.conf do adresáře /var/lib/pgsql/9.6/data s následujícím obsahem.

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

Spouštíme PostgreSQL. PostgreSQL spustí proces obnovy z archivovaných WAL a teprve poté se databáze otevře.

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

Obnova na určitou dobu.

Pokud chceme obnovit databázi do určité minuty, přidáme do recovery.conf parametr recovery_target_time — uvedeme přesně, na jakou dobu chceme databázi obnovit.

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

Po obnově se podíváme na tabulku 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

Spouštíme PostgreSQL. PostgreSQL spustí proces obnovy z archivovaných WAL a teprve poté se databáze otevře.

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

Testování

Generujeme databázi o velikosti 1 GB, jak je popsáno zde. https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Žádáme o velikost bucketu po vygenerování 1 GB dat.

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

s4cmd — bezplatný nástroj příkazového řádku pro práci s daty uloženými v úložišti Amazon S3. Tento nástroj je napsán v programovacím jazyce Python, a díky tomu může být použit v operačních systémech Windows i Linux.

Nainstalujeme s4cmd.

pip install s4cmd

LZ4

s4cmd --endpoint-url=http://ip-adresa-serveru-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822       s3://pg-backups/wal_005/
840 MB ve formátu lz4 pouze WAL logy

Úplný backup s lz4 - 1 GB dat
time backup_push.sh
real 0m18.582s

Velikost S3 bucketu po úplném backupu

581480085       s3://pg-backups/basebackups_005/
842374424   s3://pg-backups/wal_005
581 MB zabírá úplný backup

LZMA

Po vygenerování 1 GB dat
338413694       s3://pg-backups/wal_005/
338 MB logů ve formátu lzma

Čas generování úplného backupu
time backup_push.sh
real    5m25.054s

Velikost bucketu v S3
270310495       s3://pg-backups/basebackups_005/
433485092   s3://pg-backups/wal_005/

270 MB zabírá úplný backup ve formátu lzma

Brotli

Po vygenerování 1 GB dat
459229886       s3://pg-backups/wal_005/
459 MB logů ve formátu brotli

Čas generování úplného backupu
real    0m23.408s

Velikost bucketu v S3
312960942       s3://pg-backups/basebackups_005/
459309262   s3://pg-backups/wal_005/

312 MB zabírá úplný backup ve formátu brotli

Srovnání výsledků na grafu.