ProHoster > Blog > administração > Introdução ao sistema de backup wal-g PostgreSQL

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

WAL-G é uma ferramenta simples e eficaz para fazer backup do PostgreSQL nas nuvens. Em termos de funcionalidade principal, é o herdeiro da popular ferramenta WAL-E, mas reescrito em Go. Mas há um novo recurso importante no WAL-G - cópias delta. cópias delta WAL-G armazene páginas de arquivos que foram alteradas desde a versão de backup anterior. WAL-G implementa várias tecnologias para paralelizar backups. WAL-G é muito mais rápido que WAL-E.

Detalhes de como o wal-g funciona podem ser encontrados no artigo: Fazemos overclock do backup. Palestra Yandex

O protocolo de armazenamento S3 tornou-se popular para armazenamento de dados. Uma das vantagens do S3 é a possibilidade de acesso via API, que permite organizar uma interação flexível com o armazenamento, incluindo acesso público de leitura, enquanto a atualização das informações no armazenamento ocorre apenas por pessoas autorizadas.

Existem diversas implementações de armazenamento público e privado que utilizam o protocolo S3. Hoje veremos uma solução popular para organizar pequenos armazenamentos - Minio.

Um único servidor PostgreSQL é adequado para testar o wal-g, e 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

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

vi /etc/minio/minio.conf

Se você não usará o nginx antes do Minio, precisará alterar

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Lançando o Minio

systemctl start minio

Vá para a interface da web do Minio http://ip-адрес-сервера-minio:9000 e crie um bucket (por exemplo, pg-backups).

Servidor de banco de dados

WAL-G em rpm é montado por mim (Anton Patsev). Github, Fedora COPR.

Quem não possui um sistema baseado em RPM, utilize o site oficial instrução por instalação.

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

Instale o Walg.

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

Verificando a versão wal-g.

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

Edite /etc/wal-gd/server-s3.conf de acordo com suas necessidades.

Os arquivos de configuração e os arquivos de dados usados ​​por um cluster de banco de dados são tradicionalmente armazenados juntos no diretório de dados do cluster, comumente chamado de 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ê especifica WALG_DELTA_MAX_STEPS - o número de etapas que o backup delta é máximo a partir do backup base e especifica a política de cópia delta. Você faz uma cópia do último delta existente ou faz um delta do backup completo original. Isso é necessário caso o mesmo componente do banco de dados esteja sempre mudando em seu banco de dados, os mesmos dados estejam constantemente mudando.

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

Inicializamos o banco de dados.

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

Se você estiver testando em 1 servidor, será necessário reconfigurar o parâmetro wal_level para arquivar para PostgreSQL inferior à versão 10 e réplica para PostgreSQL versão 10 e anteriores.

wal_level = archive

Vamos fazer backup dos arquivos WAL a cada 60 segundos usando o próprio PostgreSQL. No prod, você terá um valor archive_timeout diferente.

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

Iniciando o PostgreSQL

systemctl start postgresql-9.6

Em um console separado, verificamos se há erros nos logs do PostgreSQL: (altere postgresql-Wed.log para o atual).

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

Vamos para o psql.

su - postgres
psql

Crie um banco de dados em psql

Crie uma tabela no banco de dados test1.

create database test1;

Mude para o teste do banco de dados.

postgres=# c test1;

Criamos a tabela indexing_table.

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

Adicionando dados.

Começamos a inserir dados. Estamos esperando 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

Observamos os registros da tabela no 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 string é a hora atual.

Veja a lista de backups completos

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

Teste de recuperação

Recuperação total com rolagem de todos os WAL disponíveis.

Pare o Postgresql.

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

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

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

Extração de backup concluída.

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

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

Iniciamos o PostgreSQL. O PostgreSQL iniciará o processo de recuperação dos WALs arquivados e só então o banco de dados será aberto. 

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

Recuperação por um certo tempo.

Se quisermos restaurar o banco de dados até um determinado minuto, adicionamos o parâmetro recovery_target_time ao recovery.conf - indicamos a que horas restaurar o banco de dados.

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

Após a recuperação, observe 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

Iniciamos o PostgreSQL. O PostgreSQL iniciará o processo de recuperação dos WALs arquivados e só então o banco de dados será aberto. 

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

Teste

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

Solicitar o tamanho do bucket após gerar 1 GB 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 residentes no armazenamento Amazon S3. O utilitário é escrito na linguagem de programação python e, por isso, pode ser usado em sistemas operacionais Windows e Linux.

Instalando 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ção dos resultados no gráfico.

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

Como você pode ver, o Brotli é comparável em tamanho ao LZMA, mas o backup é realizado no tempo LZ4.

Bate-papo da comunidade PostgreSQL de língua russa: https://t.me/pgsql

Por favor, dê uma estrela ao Github se você usar wal-g

Fonte: habr.com

Adicionar um comentário