Introductie tot het wal-g back-upsysteem voor PostgreSQL

WAL-G — een eenvoudige en effectieve tool voor het maken van back-ups van PostgreSQL naar de cloud. Functioneel gezien is het de opvolger van de populaire tool WAL-E, maar herschreven in Go. Maar WAL-G heeft één belangrijke nieuwe functie — delta-back-ups. Delta-back-ups WAL-G bewaren de pagina's van bestanden die zijn gewijzigd ten opzichte van de vorige versie van de back-up. WAL-G implementeert een behoorlijk aantal technologieën voor het paralleliseren van back-ups. WAL-G werkt veel sneller dan WAL-E.

Details over het gebruik van wal-g zijn te vinden in het artikel: Versnellen van de back-up. Lezing van Yandex

Het S3-opslagprotocol is populair geworden voor gegevensopslag. Een van de voordelen van S3 is de toegang via API, wat flexibele interactie met de opslag mogelijk maakt, inclusief publiek lezen, terwijl updates alleen door geautoriseerde personen kunnen worden uitgevoerd.

Er zijn verschillende open en privé-implementaties van opslagsystemen die werken op basis van het S3-protocol. Vandaag bekijken we een populaire oplossing voor het organiseren van kleine opslagoplossingen — Minio.

Voor het testen van wal-g is één PostgreSQL-server voldoende, en Minio wordt gebruikt als vervanging voor S3.

Minio Server

Installatie van Minio

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

Wijzig de AccessKey en SecretKey in /etc/minio/minio.conf

vi /etc/minio/minio.conf

Als je nginx niet voor Minio gebruikt, moet je wijzigen

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Start Minio

systemctl start minio

Ga naar de webinterface van Minio http://ip-adres-van-de-minio-server:9000 en maak een bucket aan (bijvoorbeeld pg-backups).

Database Server

WAL-G wordt door mij (Anton Patsev) in rpm gebouwd. Github, Fedora COPR.

Voor degenen zonder een RPM-gebaseerd systeem gebruik de officiële handleiding installatiehandleiding.

Naast de wal-g-binaire zijn er scripts die variabelen importeren uit het bestand /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

Installeer wal-g.

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

Controleer de versie van wal-g.

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

Bewerk /etc/wal-g.d/server-s3.conf naar eigen behoefte.

Configuratiebestanden en gegevensbestanden die door de database-cluster worden gebruikt, worden traditioneel samen opgeslagen in de datamap van de cluster, die meestal wordt genoemd 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 # Какой метод сжатия использовать.

Bij het configureren van WAL-G geef je WALG_DELTA_MAX_STEPS op — het aantal stappen dat de delta-back-up maximaal van de base-back-up af mag staan, en je geeft de delta-duplicatiepolitiek op. Je maakt ofwel een kopie van de laatste bestaande delta, of je maakt een delta vanaf de oorspronkelijke volledige back-up. Dit is nodig voor het geval dat in je database steeds dezelfde component van de database verandert, dezelfde gegevens continu worden gewijzigd.

We installeren de DB.

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

We initialiseren de db.

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

Als je test op 1 server, moet je de parameter wal_level instellen op archive voor PostgreSQL versies lager dan 10, en replica voor PostgreSQL versie 10 en hoger.

wal_level = archive

We maken back-ups van de WAL-archieven elke 60 seconden met PostgreSQL zelf. In productie heb je een andere waarde voor archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Elke 60 seconden wordt het archive_command uitgevoerd.

We starten PostgreSQL

systemctl start postgresql-9.6

In een aparte console bekijken we de PostgreSQL-logboeken op fouten: (vervang postgresql-Wed.log door het huidige).

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

We gaan naar psql.

su - postgres
psql

In psql maken we de DB.

We creëren een tabel in de db test1.

create database test1;

We schakelen over naar de db test.

postgres=# c test1;

We creëren een tabel indexing_table.

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

Gegevens toevoegen.

We starten met het invoegen van gegevens. Wacht 10-20 minuten.

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

Zorg ervoor dat we een volledige back-up maken.

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

We bekijken de records in de tabel in de db 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+

De regel is de huidige tijd.

We bekijken de lijst van volledige back-ups

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

Testen van herstel

Volledig herstel met het toepassen van alle beschikbare WAL.

We stoppen PostgreSQL.

We verwijderen alles uit de map /var/lib/pgsql/9.6/data.

We starten het script /usr/local/bin/backup-fetch.sh als gebruiker postgres.

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

Back-upextractie voltooid.

We voegen recovery.conf toe aan de map /var/lib/pgsql/9.6/data met de volgende inhoud.

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

We starten PostgreSQL. PostgreSQL zal het recoveryproces uit de archief-WAL's opstarten, en pas daarna zal de database geopend worden.

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

Herstel naar een bepaald tijdstip.

Als we de database tot een bepaald moment willen herstellen, voegen we de parameter recovery_target_time toe in recovery.conf — we geven aan op welk tijdstip we de database willen herstellen.

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

Na het herstel bekijken we de tabel 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

We starten PostgreSQL. PostgreSQL zal het recoveryproces uit de archief-WAL's opstarten, en pas daarna zal de database geopend worden.

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

Testen

We genereren een 1GB database zoals hier beschreven. https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

We vragen de grootte van de bucket na het genereren van 1GB gegevens.

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

s4cmd is een gratis opdrachtregeltool voor het werken met gegevens die zijn opgeslagen in Amazon S3. De tool is geschreven in de programmeertaal python, waardoor deze op zowel Windows als Linux kan worden gebruikt.

We installeren s4cmd.

pip install s4cmd

LZ4

s4cmd --endpoint-url=http://ip-adres-van-de-server-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822       s3://pg-backups/wal_005/
840 MB in lz4-formaat alleen voor WAL-logboeken

Volledige backup in lz4 - 1GB gegevens
time backup_push.sh
real 0m18.582s

Grootte van de S3-bucket na volledige backup

581480085       s3://pg-backups/basebackups_005/
842374424   s3://pg-backups/wal_005
581 MB neemt volledige backup in beslag

LZMA

Na het genereren van 1GB gegevens
338413694       s3://pg-backups/wal_005/
338 MB logboeken in lzma-formaat

Tijd voor het genereren van de volledige backup
time backup_push.sh
real    5m25.054s

Grootte van de bucket in S3
270310495       s3://pg-backups/basebackups_005/
433485092   s3://pg-backups/wal_005/

270 MB neemt volledige backup in lzma-formaat in beslag.

Brotli

Na het genereren van 1GB gegevens
459229886       s3://pg-backups/wal_005/
459 MB logboeken in brotli-formaat

Tijd voor het genereren van de volledige backup
real    0m23.408s

Grootte van de bucket in S3
312960942       s3://pg-backups/basebackups_005/
459309262   s3://pg-backups/wal_005/

312 MB neemt volledige backup in beslag in brotli-formaat.

Vergelijking van de resultaten in een grafiek.

Introductie tot het wal-g back-upsysteem voor PostgreSQL

We zien dat Brotli qua formaat vergelijkbaar is met LZMA, maar de backup wordt uitgevoerd in de tijd van LZ4.

Chat van de Spaanstalige PostgreSQL-gemeenschap: https://t.me/pgsql

Geef alsjeblieft een ster op Github als je het gebruikt. wal-g

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster