🥇Introduzione al sistema di backup wal-g di PostgreSQL

WAL-G — uno strumento semplice ed efficace per il backup di PostgreSQL nel cloud. Nella sua funzionalità principale è l'erede di un popolare strumento WAL-E, riscritto in Go. Tuttavia, WAL-G ha una nuova caratteristica importante: le copie delta. Le copie delta WAL-G memorizzano le pagine dei file che sono cambiate dalla versione precedente del backup. WAL-G implementa molte tecnologie per il parallelismo dei backup. WAL-G funziona molto più velocemente di WAL-E.

Puoi leggere maggiori dettagli sul funzionamento di wal-g nell'articolo: Accelerando il backup. Lezione di Yandex

Il protocollo di archiviazione S3 è diventato popolare per la memorizzazione dei dati. Uno dei vantaggi di S3 è la possibilità di accesso tramite API, che consente di organizzare un'interazione flessibile con lo storage, inclusa l'accesso pubblico in lettura, mentre l'aggiornamento delle informazioni nello storage avviene solo da parte di persone autorizzate.

Esistono diverse implementazioni sia aperte che private di storage che operano seguendo il protocollo S3. Oggi esamineremo una soluzione popolare per l'organizzazione di piccoli storage: Minio.

Per testare wal-g sarà sufficiente un server PostgreSQL, mentre si utilizzerà Minio come sostituto di S3.

Server Minio

Installazione di Minio

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

Modifica AccessKey e SecretKey in /etc/minio/minio.conf

vi /etc/minio/minio.conf

Se non utilizzi nginx davanti a Minio, dovrai modificare

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Avviamo Minio

systemctl start minio

Accediamo all'interfaccia web di Minio http://ip-address-of-minio-server:9000 e creiamo un bucket (ad esempio, pg-backups).

Server DB

Compilo WAL-G in rpm io stesso (Anton Patsev). Github, Fedora COPR.

Chi non ha un sistema basato su RPM utilizzi la documentazione ufficiale istruzione per l'installazione.

Insieme al binario wal-g in rpm ci sono script che importano le variabili dal file /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

Installa wal-g.

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

Controlliamo la versione di wal-g.

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

Modifica /etc/wal-g.d/server-s3.conf secondo le tue esigenze.

I file di configurazione e i file dati utilizzati dal cluster del database sono tradizionalmente memorizzati insieme nella cartella dati del cluster, che di solito viene chiamata 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 # Какой метод сжатия использовать.

Quando configuri WAL-G, specifichi WALG_DELTA_MAX_STEPS — il numero massimo di passi a cui può distaccarsi dal backup base il backup delta, e imposti la politica della copia delta. O fai una copia dall'ultima delta esistente, o crei una delta dal backup completo iniziale. Questo è necessario nel caso in cui nella tua database cambi sempre la stessa componente del DB, gli stessi dati vengono costantemente modificati.

Installiamo il 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

Inizializziamo il db.

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

Se stai testando su un server, devi riconfigurare il parametro wal_level su archive per PostgreSQL inferiore alla versione 10, e replica per PostgreSQL versione 10 e superiore.

wal_level = archive

Effettuiamo backup degli archivi WAL ogni 60 secondi usando PostgreSQL stesso. In produzione avrai un valore diverso per archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Ogni 60 secondi verrà eseguita la comando archive_command.

Avviamo PostgreSQL

systemctl start postgresql-9.6

In una console separata, controlliamo i log di PostgreSQL per eventuali errori: (sostituisci postgresql-Wed.log con quello attuale).

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

Accediamo a psql.

su - postgres
psql

In psql creiamo il DB.

Creiamo una tabella nel db test1.

create database test1;

Passiamo al db test.

postgres=# c test1;

Creiamo la tabella indexing_table.

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

Aggiunta di dati.

Iniziamo a inserire dati. Aspetta 10-20 minuti.

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

Assicurati di fare un backup completo.

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

Controlliamo le registrazioni nella tabella del 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+

La riga rappresenta l'ora attuale.

Controlliamo l'elenco dei backup completi

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

Test di ripristino

Ripristino completo con l'applicazione di tutti i WAL disponibili.

Ferma PostgreSQL.

Cancella tutto dalla cartella /var/lib/pgsql/9.6/data.

Esegui lo script /usr/local/bin/backup-fetch.sh come utente postgres.

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

Estrazione del backup completata.

Aggiungi recovery.conf nella cartella /var/lib/pgsql/9.6/data con il seguente contenuto.

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

Avviamo PostgreSQL. PostgreSQL avvierà il processo di recovery dagli WAL archiviati, e solo allora il database si aprirà.

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

Ripristino a un momento specifico.

Se vogliamo ripristinare il database a un minuto specifico, allora aggiungiamo il parametro recovery_target_time in recovery.conf per indicare a quale tempo ripristinare il database.

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

Dopo il ripristino, controlliamo la tabella 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

Avviamo PostgreSQL. PostgreSQL avvierà il processo di recovery dagli WAL archiviati, e solo allora il database si aprirà.

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

Test

Generiamo un database da 1GB come descritto qui https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Richiediamo la dimensione del bucket dopo la generazione di 1GB di dati.

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

s4cmd — uno strumento gratuito da riga di comando per lavorare con i dati archiviati in Amazon S3. Questa utility è scritta in Python, il che la rende utilizzabile sia su sistemi operativi Windows che Linux.

Installiamo s4cmd

pip install s4cmd

LZ4

s4cmd --endpoint-url=http://ip-address-del-server-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822       s3://pg-backups/wal_005/
840 MB in formato lz4 solo log WAL

Backup completo con lz4 - 1GB di dati
time backup_push.sh
real 0m18.582s

Dimensione del bucket S3 dopo il backup completo

581480085       s3://pg-backups/basebackups_005/
842374424   s3://pg-backups/wal_005
581 MB occupa il backup completo

LZMA

Dopo la generazione di 1GB di dati
338413694       s3://pg-backups/wal_005/
338 MB di log in formato lzma

Tempo di generazione del backup completo
time backup_push.sh
real    5m25.054s

Dimensione del bucket in S3
270310495       s3://pg-backups/basebackups_005/
433485092   s3://pg-backups/wal_005/

270 MB occupa il backup completo in formato lzma

Brotli

Dopo la generazione di 1GB di dati
459229886       s3://pg-backups/wal_005/
459 MB di log in formato brotli

Tempo di generazione del backup completo
time backup_push.sh
real    0m23.408s

Dimensione del bucket in S3
312960942       s3://pg-backups/basebackups_005/
459309262   s3://pg-backups/wal_005/

312 MB occupa il backup completo in formato brotli

Confronto dei risultati nel grafico.