ProHoster > Log > administrasjon > Vi introduserer wal-g PostgreSQL backup-systemet

Vi introduserer wal-g PostgreSQL backup-systemet

WAL-G er et enkelt og effektivt verktøy for å sikkerhetskopiere PostgreSQL til skyen. Når det gjelder hovedfunksjonaliteten, er det etterfølgeren til det populære verktøyet WAL-E, men omskrevet i Go. Men WAL-G har en viktig ny funksjon: deltakopier. Delta kopier WAL-G lagre sider med filer som har endret seg siden forrige versjon av sikkerhetskopien. WAL-G implementerer ganske mange teknologier for parallellisering av sikkerhetskopier. WAL-G er mye raskere enn WAL-E.

Detaljer om hvordan wal-g fungerer finner du i artikkelen: Vi fremskynder sikkerhetskopieringen. Yandex foredrag

S3-lagringsprotokollen har blitt populær for lagring av data. En av fordelene med S3 er muligheten for tilgang via API, som lar deg organisere fleksibel interaksjon med lagringen, inkludert offentlig lesetilgang, mens oppdatering av informasjon i lagringen kun skjer av autoriserte personer.

Det er flere offentlige og private lagringsimplementeringer som bruker S3-protokollen. I dag skal vi se på en populær løsning for organisering av små lagringsanlegg - Minio.

En enkelt PostgreSQL-server er egnet for testing av wal-g, og Minio brukes som erstatning for S3.

Minio server

Installerer Minio

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

Redigering av AccessKey og SecretKey i /etc/minio/minio.conf

vi /etc/minio/minio.conf

Hvis du ikke vil bruke nginx før Minio, må du endre

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Start Minio

systemctl start minio

Gå til Minio-nettgrensesnittet http://ip-адрес-сервера-minio:9000 og lag en bøtte (for eksempel pg-sikkerhetskopier).

DB server

Jeg monterer WAL-G i rpm (Anton Patsev). Github, Fedora COPR.

For de som ikke har et RPM-basert system, bruk det offisielle instruksjon på installasjon.

Sammen med wal-g binær, inneholder rpm skript som importerer variabler fra filen /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

Installer wal-g.

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

Sjekker versjonen av wal-g.

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

Rediger /etc/wal-gd/server-s3.conf for å passe dine behov.

Konfigurasjonsfiler og datafiler som brukes av en databaseklynge lagres tradisjonelt sammen i klyngedatakatalogen, ofte referert til som 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 # Какой метод сжатия использовать.

Når du setter opp WAL-G, spesifiserer du WALG_DELTA_MAX_STEPS - antall trinn som delta backup er maksimalt fjernt fra basis backup, og spesifiserer delta kopi policy. Enten lager du en kopi fra det siste eksisterende deltaet, eller så lager du et delta fra den originale full backup. Dette er nødvendig for tilfellet når den samme databasekomponenten alltid endres i databasen din, de samme dataene endres hele tiden.

Installere databasen.

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

La oss initialisere databasen.

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

Hvis du tester på 1 server, må du rekonfigurere wal_level-parameteren for å arkivere for PostgreSQL-versjon mindre enn 10, og replika for PostgreSQL-versjon 10 og eldre.

wal_level = archive

La oss sikkerhetskopiere WAL-arkiver hvert 60. sekund ved å bruke PostgreSQL selv. I produksjon vil du ha en annen archive_timeout-verdi.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Каждые 60 секунд будет выполнятся команда archive_command.

La oss starte PostgreSQL

systemctl start postgresql-9.6

I en egen konsoll ser vi på PostgreSQL-loggene for feil: (endre postgresql-Wed.log til den gjeldende).

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

La oss gå til psql.

su - postgres
psql

Vi lager en database i psql.

Lag en tabell i test1-databasen.

create database test1;

Bytt til testdatabasen.

postgres=# c test1;

Opprett en tabellindekseringstabell.

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

Legger til data.

La oss starte datainnsetting. Vi venter 10-20 minutter.

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

Sørg for å lage en fullstendig sikkerhetskopi.

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

Vi ser på oppføringene i tabellen i test1-databasen

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+

Strengen er gjeldende tid.

Vi ser på listen over fullstendige sikkerhetskopier

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

Gjenopprettingstesting

Full gjenoppretting med å rulle over all tilgjengelig WAL.

Stopper Postgresql.

Vi sletter alt fra mappen /var/lib/pgsql/9.6/data.

Kjør skriptet /usr/local/bin/backup-fetch.sh fra postgres-brukeren.

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

Utvinning av sikkerhetskopi fullført.

Legg recovery.conf til mappen /var/lib/pgsql/9.6/data med følgende innhold.

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

Start PostgreSQL. PostgreSQL vil starte gjenopprettingsprosessen fra den arkiverte WAL, og først da åpnes databasen. 

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

Restitusjon for en viss tid.

Hvis vi ønsker å gjenopprette databasen til et bestemt minutt, legger vi til recovery.conf parameteren recovery_target_time - vi angir når databasen skal gjenopprettes.

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

Etter gjenoppretting, se på indexing_table-tabellen

 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

Start PostgreSQL. PostgreSQL vil starte gjenopprettingsprosessen fra den arkiverte WAL, og først da åpnes databasen. 

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

Testing

Vi genererer en 1GB database som beskrevet her https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Vi ber om bøttestørrelsen etter å ha generert 1 GB data.

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

s4cmd er et gratis kommandolinjeverktøy for å jobbe med data som ligger i Amazon S3-lagring. Verktøyet er skrevet i programmeringsspråket python, og takket være dette kan det brukes i både Windows- og Linux-operativsystemer.

Installer 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

Sammenligning av resultater på en graf.

Vi introduserer wal-g PostgreSQL backup-systemet

Som vi kan se, er Brotli sammenlignbar i størrelse med LZMA, men sikkerhetskopiering utføres i LZ4-tid.

Chat fra det russisktalende PostgreSQL-fellesskapet: https://t.me/pgsql

Gi en stjerne på Github hvis du bruker wal-g

Kilde: www.habr.com

Legg til en kommentar