Introducere în sistemul de backup wal-g PostgreSQL

WAL-G este un instrument simplu și eficient pentru a face copii de rezervă PostgreSQL în cloud. În ceea ce privește funcționalitatea sa principală, este moștenitorul popularului instrument WAL-E, dar rescris în Go. Dar există o nouă caracteristică importantă în WAL-G - copiile delta. copii delta WAL-G stocați pagini cu fișiere care s-au modificat de la versiunea anterioară de rezervă. WAL-G implementează destul de multe tehnologii pentru paralelizarea backup-urilor. WAL-G este mult mai rapid decât WAL-E.

Detalii despre cum funcționează wal-g pot fi găsite în articol: Overclockăm backupul. prelegere Yandex

Protocolul de stocare S3 a devenit popular pentru stocarea datelor. Unul dintre avantajele S3 este capacitatea de acces prin API, care vă permite să organizați interacțiunea flexibilă cu stocarea, inclusiv accesul public la citire, în timp ce actualizarea informațiilor din stocare are loc doar de către persoane autorizate.

Există mai multe implementări de stocare publice și private care utilizează protocolul S3. Astăzi ne vom uita la o soluție populară pentru organizarea depozitelor mici - Minio.

Un singur server PostgreSQL este bine pentru testarea wal-g, iar Minio este folosit ca înlocuitor pentru S3.

Serverul Minio

Instalare Minio

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

Editați AccessKey și SecretKey în /etc/minio/minio.conf

vi /etc/minio/minio.conf

Dacă nu veți folosi nginx înainte de Minio, atunci trebuie să îl schimbați

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Lansarea Minio

systemctl start minio

Accesați interfața web Minio http://ip-адрес-сервера-minio:9000 și creați o găleată (de exemplu, pg-backups).

Server DB

WAL-G în rpm este asamblat de mine (Anton Patsev). Github, Fedora COPR.

Cine nu are un sistem bazat pe RPM, folosește oficial instrucțiuni prin instalare.

Împreună cu binarul wal-g, rpm conține scripturi care importă variabile din fișierul /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

Instalați walg.

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

Se verifică versiunea wal-g.

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

Editați /etc/wal-gd/server-s3.conf după nevoile dvs.

Fișierele de configurare și fișierele de date utilizate de un cluster de baze de date sunt în mod tradițional stocate împreună în directorul de date cluster, denumit în mod obișnuit ca 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 # Какой метод сжатия использовать.

Când configurați WAL-G, specificați WALG_DELTA_MAX_STEPS - numărul de pași în care backup-ul delta este maxim față de backup-ul de bază și specificați politica de copiere delta. Fie faci o copie din ultima delta existentă, fie faci o delta din backupul complet original. Acest lucru este necesar în cazul în care aceeași componentă a bazei de date se schimbă mereu în baza de date, aceleași date se schimbă în mod constant.

Instalarea bazei de date.

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

Inițializam baza de date.

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

Dacă testați pe un singur server, atunci trebuie să reconfigurați parametrul wal_level pentru a arhiva pentru PostgreSQL mai puțin decât versiunea 1 și replica pentru PostgreSQL versiunea 10 și mai veche.

wal_level = archive

Să facem backup pentru arhivele WAL la fiecare 60 de secunde folosind PostgreSQL însuși. Pe prod, veți avea o altă valoare archive_timeout.

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

Pornirea PostgreSQL

systemctl start postgresql-9.6

Într-o consolă separată, ne uităm la jurnalele PostgreSQL pentru erori: (schimbați postgresql-Wed.log în cel curent).

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

Să mergem la psql.

su - postgres
psql

Creați o bază de date în psql

Creați un tabel în baza de date test1.

create database test1;

Treceți la testul bazei de date.

postgres=# c test1;

Creăm tabelul indexing_table.

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

Adăugarea datelor.

Începem să introducem date. Asteptam 10-20 de minute.

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

Asigurați-vă că faceți o copie de rezervă completă.

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

Ne uităm la înregistrările din tabelul din baza de date 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+

Șirul este ora curentă.

Vedeți lista de copii de rezervă complete

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

Testare de recuperare

Recuperare completă cu rularea tuturor WAL disponibile.

Opriți Postgresql.

Ștergeți totul din folderul /var/lib/pgsql/9.6/data.

Rulați scriptul /usr/local/bin/backup-fetch.sh ca utilizator postgres.

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

Extragerea copiei de rezervă s-a încheiat.

Adăugați recovery.conf în folderul /var/lib/pgsql/9.6/data cu următorul conținut.

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

Pornim PostgreSQL. PostgreSQL va începe procesul de recuperare din WAL-urile arhivate și numai atunci se va deschide baza de date.

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

Recuperare pentru un anumit timp.

Dacă dorim să restabilim baza de date până la un anumit minut, atunci adăugăm parametrul recovery_target_time la recovery.conf - indicăm la ce oră să restabilim baza de date.

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

După recuperare, uitați-vă la tabelul 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

Pornim PostgreSQL. PostgreSQL va începe procesul de recuperare din WAL-urile arhivate și numai atunci se va deschide baza de date.

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

Testarea

Generarea unei baze de date de 1 GB așa cum este descris aici https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Solicitarea dimensiunii compartimentului după generarea a 1 GB de date.

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

s4cmd este un instrument gratuit de linie de comandă pentru lucrul cu date care se află în stocarea Amazon S3. Utilitarul este scris în limbajul de programare python, iar din acest motiv poate fi folosit atât în ​​sistemele de operare Windows, cât și în Linux.

Instalarea 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

Comparația rezultatelor pe diagramă.

Introducere în sistemul de backup wal-g PostgreSQL

După cum puteți vedea, Brotli este comparabil ca dimensiune cu LZMA, dar backup-ul este efectuat în timp LZ4.

Chat al comunității de limbă rusă PostgreSQL: https://t.me/pgsql

Vă rugăm să acordați o stea lui Github dacă utilizați wal-g

Sursa: www.habr.com

Adauga un comentariu