— 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 , maar herschreven in Go. Maar WAL-G heeft één belangrijke nieuwe functie — delta-back-ups. Delta-back-ups 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:
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 minioWijzig de AccessKey en SecretKey in /etc/minio/minio.conf
vi /etc/minio/minio.confAls je nginx niet voor Minio gebruikt, moet je wijzigen
--address 127.0.0.1:9000--address 0.0.0.0:9000Start Minio
systemctl start minioGa naar de webinterface van Minio en maak een bucket aan (bijvoorbeeld pg-backups).
Database Server
WAL-G wordt door mij (Anton Patsev) in rpm gebouwd. , .
Voor degenen zonder een RPM-gebaseerd systeem gebruik de officiële 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.shInstalleer wal-g.
yum -y install yum-plugin-copr
yum copr enable -y antonpatsev/wal-g
yum install -y wal-gControleer de versie van wal-g.
wal-g --version
wal-g versie v0.2.14Bewerk /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 mcWe initialiseren de db.
/usr/pgsql-9.6/bin/postgresql96-setup initdb
Initializing database ... OKAls 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 = archiveWe 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.6In 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.logWe gaan naar psql.
su - postgres
psqlIn 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;
doneZorg ervoor dat we een volledige back-up maken.
su - postgres
/usr/local/bin/backup-push.shWe 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.shTesten 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.shBack-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.logHerstel 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+00We 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.logTesten
We genereren een 1GB database zoals hier beschreven.
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 MBs4cmd 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 s4cmdLZ4
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 beslagLZMA
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.

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:
Geef alsjeblieft een ster op Github als je het gebruikt.
Bron: habr.com
