🥇Introduzione al sistema di backup wal-g per PostgreSQL

WAL-G — uno strumento semplice ed efficace per il backup di PostgreSQL nel cloud. Per la sua funzionalità principale, è l'erede di uno strumento popolare WAL-E, ma riscritto in Go. Ma in WAL-G c'è una importante novità: le copie delta. Le copie delta WAL-G memorizzano le pagine dei file che sono cambiate rispetto alla versione precedente del backup. WAL-G implementa molte tecnologie per il parallelismo dei backup. WAL-G funziona molto più velocemente rispetto a WAL-E.

Puoi leggere ulteriori dettagli sul funzionamento di wal-g nell'articolo: Acceleriamo 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 interazioni flessibili con lo storage, inclusi accessi pubblici in lettura, mentre l'aggiornamento delle informazioni nello storage avviene solo da parte di utenti autorizzati.

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

Per testare wal-g è sufficiente un server PostgreSQL, mentre Minio è utilizzato 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

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

vi /etc/minio/minio.conf

Se non utilizzerai 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-indirizzo-server-minio: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 guida ufficiale istruzioni per l'installazione.

Insieme al binario wal-g in rpm sono presenti 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

Installiamo 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 directory dei 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 # Какой метод сжатия использовать.

Durante la configurazione di WAL-G, specificate WALG_DELTA_MAX_STEPS: il numero massimo di passaggi che la copia delta può distaccarsi dal backup base e indicate la politica di copia delta. Potete fare una copia dall'ultima delta esistente oppure fare una delta dal backup completo originale. Questo è necessario nel caso in cui una certa componente del database cambi continuamente, gli stessi dati vengano costantemente modificati.

Installiamo il database.

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 database.

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

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

wal_level = archive

Effettueremo il backup degli archivi WAL ogni 60 secondi utilizzando PostgreSQL stesso. In produzione avrete un altro valore per archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Il comando archive_command verrà eseguito ogni 60 secondi.

Avviamo PostgreSQL

systemctl start postgresql-9.6

In una console separata controlliamo i log di PostgreSQL per errori: (sostituite postgresql-Wed.log con l'attuale).

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

Accediamo a psql.

su - postgres
psql

In psql creiamo il database.

Creiamo una tabella nel database test1.

create database test1;

Passiamo al database 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 l'inserimento dei dati. Aspettiamo 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

È fondamentale effettuare un backup completo.

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

Controlliamo le registrazioni nella tabella nel database 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 indica l'ora corrente.

Controlliamo l'elenco dei backup completi

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

Test di ripristino

Ripristino completo applicando tutti i WAL disponibili.

Fermiamo PostgreSQL.

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

Eseguiamo lo script /usr/local/bin/backup-fetch.sh con l'utente postgres.

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

Estrazione del backup completata.

Aggiungiamo 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 recupero dagli archivi WAL e solo dopo il database verrà aperto.

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, aggiungiamo nel recovery.conf il parametro recovery_target_time — indichiamo a quale ora 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 guardiamo 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 recupero dagli archivi WAL e solo dopo il database verrà aperto.

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

Test

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

Richiediamo la dimensione del bucket dopo aver generato 1 GB di dati.

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

s4cmd è uno strumento gratuito da linea di comando per lavorare con i dati memorizzati su Amazon S3. L'utilità è scritta in Python, perciò può essere utilizzata sia su Windows che su Linux.

Installiamo 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\/\n840 MB in formato lz4 solo log WAL

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

Dimensione del bucket S3 dopo il backup completo

581480085       s3:\/\/pg-backups\/basebackups_005\/\n842374424   s3:\/\/pg-backups\/wal_005\n581 MB occupa il backup completo

LZMA

Dopo la generazione di 1 GB di dati
338413694       s3:\/\/pg-backups\/wal_005\/\n338 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\/\n433485092   s3:\/\/pg-backups\/wal_005\/\n
270 MB occupa il backup completo in formato lzma

Brotli

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

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

Dimensione del bucket in S3
312960942       s3:\/\/pg-backups\/basebackups_005\/\n459309262   s3:\/\/pg-backups\/wal_005\/\n
312 MB occupa il backup completo in formato brotli

Confronto dei risultati nel grafico.