🥇Introdução ao sistema de backup wal-g do PostgreSQL

WAL-G — uma ferramenta simples e eficaz para backup do PostgreSQL na nuvem. Em sua funcionalidade principal, é o sucessor da popular ferramenta WAL-E, mas reescrita em Go. No entanto, há uma nova característica importante no WAL-G — cópias delta. As cópias delta WAL-G guardam as páginas de arquivos que mudaram desde a versão anterior do backup. O WAL-G implementa muitas tecnologias para paralelização de backups. O WAL-G funciona muito mais rápido que o WAL-E.

Os detalhes do funcionamento do wal-g podem ser lidos no artigo: Acelerando o backup. Palestra do Yandex

O protocolo de armazenamento S3 tornou-se popular para armazenar dados. Uma das vantagens do S3 é a possibilidade de acesso através da API, permitindo a organização de uma interação flexível com o armazenamento, incluindo o acesso público para leitura, enquanto a atualização das informações no armazenamento é feita apenas por pessoas autorizadas.

Existem várias implementações, tanto abertas quanto privadas, de armazenamentos que operam usando o protocolo S3. Hoje, vamos analisar uma solução popular para a organização de pequenos armazenamentos — Minio.

Para testar o wal-g, um servidor PostgreSQL é suficiente, enquanto o Minio é usado como substituto do S3.

Servidor Minio

Instalação do Minio

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

Alteramos AccessKey e SecretKey em /etc/minio/minio.conf

vi /etc/minio/minio.conf

Se você não for usar nginx na frente do Minio, precisará alterar

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Iniciamos o Minio

systemctl start minio

Acessamos a interface web do Minio http://ip-endereço-do-servidor-minio:9000 e criamos um bucket (por exemplo, pg-backups).

Servidor de BD

Estou compilando o WAL-G em rpm (Anton Patsev). Github, Fedora COPR.

Para quem não tem sistema baseado em RPM, utilize o oficial as instruções da instalação.

Junto com o binário do wal-g em rpm, existem scripts que importam variáveis do arquivo /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

Instalamos o wal-g.

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

Verificamos a versão do wal-g.

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

Editamos /etc/wal-g.d/server-s3.conf conforme necessário.

Os arquivos de configuração e os arquivos de dados usados pelo cluster do banco de dados são tradicionalmente armazenados juntos no diretório de dados do cluster, que geralmente é chamado 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 # Какой метод сжатия использовать.

Ao configurar o WAL-G, você define o WALG_DELTA_MAX_STEPS — a quantidade máxima de passos que um backup delta pode estar distante do backup base, e especifica a política de cópia delta. Você pode fazer uma cópia da última delta existente ou fazer um delta a partir do backup completo inicial. Isso é necessário quando uma mesma parte do banco de dados muda continuamente, com os mesmos dados sendo alterados constantemente.

Instalando o banco de dados.

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

Inicializando o banco de dados.

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

Se você estiver testando em um servidor, precisará reconfigurar o parâmetro wal_level para archive para PostgreSQL abaixo da versão 10, e replica para PostgreSQL da versão 10 ou superior.

wal_level = archive

Vamos fazer o backup dos arquivos WAL a cada 60 segundos usando o próprio PostgreSQL. Em produção, você terá um valor diferente para archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # O comando archive_command será executado a cada 60 segundos.

Iniciando o PostgreSQL

systemctl start postgresql-9.6

Em um console separado, veja os logs do PostgreSQL em busca de erros: (substitua postgresql-Wed.log pelo atual).

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

Entrando no psql.

su - postgres
psql

No psql, criamos o banco de dados.

Criando uma tabela no banco de dados test1.

create database test1;

Mudando para o banco de dados test.

postgres=# c test1;

Criando a tabela indexing_table.

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

Adicionando dados.

Iniciando a inserção de dados. Aguarde de 10 a 20 minutos.

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

Certifique-se de fazer um backup completo.

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

Verificando as entradas na tabela do banco de dados 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+

A linha é o tempo atual.

Verificando a lista de backups completos

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

Testando a recuperação

Recuperação completa aplicando todos os WAL disponíveis.

Parando o PostgreSQL.

Removendo tudo da pasta /var/lib/pgsql/9.6/data.

Executando o script /usr/local/bin/backup-fetch.sh como o usuário postgres.

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

Extração do backup completa.

Adicionando recovery.conf na pasta /var/lib/pgsql/9.6/data com o seguinte conteúdo.

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

Iniciando o PostgreSQL. O PostgreSQL iniciará o processo de recuperação a partir dos arquivos WAL arquivados, e só então o banco será aberto.

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

Recuperação para um tempo específico.

Se quisermos restaurar o banco até um determinado minuto, adicionamos o parâmetro recovery_target_time em recovery.conf — indicando para que momento restaurar o banco.

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

Após a restauração, olhamos para a 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

Iniciando o PostgreSQL. O PostgreSQL iniciará o processo de recuperação a partir dos arquivos WAL arquivados, e só então o banco será aberto.

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

Testes

Geramos um banco de dados de 1GB conforme descrito aqui https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Solicitamos o tamanho do bucket após gerar 1GB de dados.

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

s4cmd — uma ferramenta de linha de comando gratuita para trabalhar com dados armazenados no Amazon S3. O utilitário é escrito na linguagem de programação Python e, por isso, pode ser usado tanto em sistemas operacionais Windows quanto Linux.

Instalamos o s4cmd

pip install s4cmd

LZ4

s4cmd --endpoint-url=http://ip-endereco-servidor-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822       s3://pg-backups/wal_005/
840 MB em formato lz4 apenas logs WAL

Backup completo com lz4 - 1GB de dados
time backup_push.sh
real 0m18.582s

Tamanho do bucket S3 após o backup completo

581480085       s3://pg-backups/basebackups_005/
842374424   s3://pg-backups/wal_005
581 MB ocupa o backup completo

LZMA

Após a geração de 1GB de dados
338413694       s3://pg-backups/wal_005/
338 MB de logs em formato lzma

Tempo de geração do backup completo
time backup_push.sh
real    5m25.054s

Tamanho do bucket no S3
270310495       s3://pg-backups/basebackups_005/
433485092   s3://pg-backups/wal_005/

270 MB ocupa o backup completo em formato lzma

Brotli

Após a geração de 1GB de dados
459229886       s3://pg-backups/wal_005/
459 MB de logs em formato brotli

Tempo de geração do backup completo
real    0m23.408s

Tamanho do bucket no S3
312960942       s3://pg-backups/basebackups_005/
459309262   s3://pg-backups/wal_005/

312 MB ocupa o backup completo em formato brotli

Comparação dos resultados em gráfico.