🥇Introducere în sistemul de backup wal-g pentru PostgreSQL

WAL-G — un instrument simplu și eficient pentru backup-ul PostgreSQL în cloud. Din punct de vedere al funcționalității sale de bază, este un succesor al instrumentului popular WAL-E, dar rescris în Go. Însă la WAL-G există o caracteristică nouă importantă — copiile delta. Copiile delta WAL-G păstrează paginile fișierelor care s-au modificat față de versiunea anterioară a backup-ului. În WAL-G sunt implementate o serie de tehnologii pentru paralelizarea backup-urilor. WAL-G funcționează mult mai repede decât WAL-E.

Detalii despre funcționarea wal-g pot fi citite în articolul: Accelerează backup-ul. Prezentarea Yandex

Protocolul de stocare S3 a devenit popular pentru stocarea datelor. Unul dintre avantajele S3 este posibilitatea de acces prin API, care permite organizarea unei interacțiuni flexibile cu stocarea, inclusiv acces public la citire, în timp ce actualizarea informațiilor în stocare se face doar de către persoane autorizate.

Există mai multe implementări care fie sunt deschise, fie private, funcționând pe baza protocolului S3. Astăzi vom analiza o soluție populară pentru organizarea unor stocări mici — Minio.

Pentru testarea wal-g, este suficient un server PostgreSQL, iar ca înlocuitor pentru S3 se folosește Minio.

Server Minio

Instalarea Minio

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

Modificăm AccessKey și SecretKey în /etc/minio/minio.conf

vi /etc/minio/minio.conf

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

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Pornim Minio

systemctl start minio

Accesăm interfața web Minio http://ip-adresa-serverului-minio:9000 și creăm un bucket (de exemplu, pg-backups).

Server DB

WAL-G în rpm îl construiesc eu (Anton Patsev). Github, Fedora COPR.

Cei care nu au un sistem bazat pe RPM, folosiți instrucțiunile oficiale instrucțiunea de instalare.

Împreună cu binarul wal-g în rpm există scripturi care importa variabile din fișierul /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

Instalăm wal-g.

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

Verificăm versiunea wal-g.

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

Edităm /etc/wal-g.d/server-s3.conf conform nevoilor.

Fișierele de configurație și fișierele de date utilizate de clusterul bazei de date sunt, tradițional, păstrate împreună în directorul de date al clusterului, care de obicei este denumit 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 maxim de pași la care delta backup-ul se îndepărtează de backup-ul de bază și specificați politica de copiere delta. Fie faceți o copie cu ultima delta existentă, fie faceți o delta din backup-ul complet inițial. Acest lucru este necesar atunci când o anumită componentă a bazei de date se schimbă constant, aceleași date sunt în continuare modificate.

Instalăm 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

Inițializăm baza de date.

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

Dacă testați pe un server, trebuie să modificați parametrul wal_level la archive pentru PostgreSQL mai mic de 10 versiuni și replica pentru PostgreSQL versiunea 10 și mai mare.

wal_level = archive

Vom face backup-ul arhivelor WAL la fiecare 60 de secunde folosind PostgreSQL. Pe producție, veți avea o altă valoare pentru archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Comanda archive_command va fi executată la fiecare 60 de secunde.

Pornim PostgreSQL

systemctl start postgresql-9.6

Într-o consolă separată, verificăm jurnalele PostgreSQL pentru erori: (schimbați postgresql-Wed.log cu cel curent).

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

Intrăm în psql.

su - postgres
psql

În psql creăm o bază de date.

Creăm o tabelă în baza de date test1.

create database test1;

Trecem la baza de date test.

postgres=# c test1;

Creăm tabela indexing_table.

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

Adăugarea de date.

Începem inserția de date. Așteptăm 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 un backup complet.

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

Verificăm î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+

Linia aceasta reprezintă timpul curent.

Verificăm lista de backup-uri complete

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

Testarea recuperării

Recuperare completă cu aplicarea tuturor WAL-urilor disponibile.

Oprim PostgreSQL.

Ștergem tot din folderul /var/lib/pgsql/9.6/data.

Executăm scriptul /usr/local/bin/backup-fetch.sh de la utilizatorul postgres.

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

Extracția backup-ului este completă.

Adăugăm 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 înclina procesul de recuperare din arhivele WAL, și abia apoi baza va fi deschisă.

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

Recuperare la un timp specific.

Dacă dorim să restaurăm baza de date până la un anumit minut, atunci în recovery.conf adăugăm parametrul recovery_target_time — specificăm la ce oră să restaurăm baza de date.

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

După restaurare, ne uităm la tabela 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 înclina procesul de recuperare din arhivele WAL, și abia apoi baza va fi deschisă.

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

Testare

Generăm o bază de date de 1GB, așa cum este descris aici https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Cerem dimensiunea bucket-ului după generarea a 1GB de date.

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

s4cmd — un instrument gratuit de linie de comandă pentru lucrul cu datele stocate în Amazon S3. Utilitarul este scris în limbajul de programare Python, iar datorită acestui lucru poate fi utilizat atât pe sistemele de operare Windows, cât și pe cele Linux.

Instalăm s4cmd

pip install s4cmd

LZ4

s4cmd --endpoint-url=http:\/\/ip-adresa-serverului-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3:\/\/pg-backups
840540822       s3:\/\/pg-backups\/wal_005\/
840 MB în format lz4 doar pentru logurile WAL

Backup complet cu lz4 - 1GB de date
time backup_push.sh
real 0m18.582s

Dimensiunea bucket-ului S3 după backup complet

581480085       s3:\/\/pg-backups\/basebackups_005\/
842374424   s3:\/\/pg-backups\/wal_005
581 MB ocupă backup-ul complet

LZMA

După generarea a 1GB de date
338413694       s3:\/\/pg-backups\/wal_005\/
338 MB de loguri în format lzma

Timpul de generare a backup-ului complet
time backup_push.sh
real    5m25.054s

Dimensiunea bucket-ului în S3
270310495       s3:\/\/pg-backups\/basebackups_005\/
433485092   s3:\/\/pg-backups\/wal_005\/

270 MB ocupă backup-ul complet în format lzma

Brotli

După generarea a 1GB de date
459229886       s3:\/\/pg-backups\/wal_005\/
459 MB de loguri în format brotli

Timpul de generare a backup-ului complet
real    0m23.408s

Dimensiunea bucket-ului în S3
312960942       s3:\/\/pg-backups\/basebackups_005\/
459309262   s3:\/\/pg-backups\/wal_005\/

312 MB ocupă backup-ul complet în format brotli

Compararea rezultatelor pe grafic.