ProHoster > Blog > Administración > Introdución ao sistema de copia de seguridade wal-g PostgreSQL

Introdución ao sistema de copia de seguridade wal-g PostgreSQL

WAL-G é unha ferramenta sinxela e eficaz para facer copias de seguridade de PostgreSQL nas nubes. En canto á súa principal funcionalidade, é o herdeiro da popular ferramenta WAL-E, pero reescrito en Go. Pero hai unha nova función importante en WAL-G: as copias delta. copias delta WAL-G almacena páxinas de ficheiros que cambiaron desde a versión de copia de seguranza anterior. WAL-G implementa moitas tecnoloxías para paralelizar copias de seguridade. WAL-G é moito máis rápido que WAL-E.

Os detalles de como funciona wal-g pódense atopar no artigo: Facemos overclock da copia de seguridade. Charla Yandex

O protocolo de almacenamento S3 fíxose popular para almacenar datos. Unha das vantaxes de S3 é a posibilidade de acceder a través da API, que permite organizar unha interacción flexible co almacenamento, incluíndo o acceso público de lectura, mentres que a actualización da información no almacenamento só se realiza por persoas autorizadas.

Existen varias implementacións de almacenamento público e privado que usan o protocolo S3. Hoxe veremos unha solución popular para organizar un pequeno almacenamento: Minio.

Un único servidor PostgreSQL está ben para probar wal-g e Minio úsase como substituto de S3.

Servidor Minio

Instalación Minio

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

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

vi /etc/minio/minio.conf

Se non vai usar nginx antes de Minio, entón debes cambiar

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Lanzamento de Minio

systemctl start minio

Vaia á interface web de Minio http://ip-адрес-сервера-minio:9000 e cree un depósito (por exemplo, pg-backups).

servidor de base de datos

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

Quen non teña un sistema baseado en RPM, use o oficial instrución mediante instalación.

Xunto co binario wal-g, rpm contén scripts que importan variables do ficheiro /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

Instalar walg.

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

Comprobando a versión wal-g.

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

Edite /etc/wal-gd/server-s3.conf segundo as súas necesidades.

Os ficheiros de configuración e os ficheiros de datos utilizados por un clúster de bases de datos gárdanse tradicionalmente xuntos no directorio de datos do clúster, denominado habitualmente como 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 WAL-G, especifica WALG_DELTA_MAX_STEPS: o número de pasos que a copia de seguridade delta é máximo desde a copia de seguridade base, e especifica a política de copia delta. Ou fai unha copia do último delta existente ou fai un delta a partir da copia de seguridade completa orixinal. Isto é necesario no caso de que o mesmo compoñente da base de datos está a cambiar sempre na súa base de datos, os mesmos datos están a cambiar constantemente.

Instalación da base de datos.

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 a base de datos.

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

Se estás a probar nun servidor, debes reconfigurar o parámetro wal_level para arquivar para PostgreSQL inferior á versión 1 e a réplica para PostgreSQL versión 10 ou anterior.

wal_level = archive

Fagamos unha copia de seguridade dos arquivos WAL cada 60 segundos usando o propio PostgreSQL. En prod, terás un valor archive_timeout diferente.

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

Iniciando PostgreSQL

systemctl start postgresql-9.6

Nunha consola separada, miramos os rexistros de PostgreSQL para detectar erros: (cambiar postgresql-Wed.log ao actual).

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

Imos a psql.

su - postgres
psql

Crear base de datos en psql

Crear unha táboa na base de datos test1.

create database test1;

Cambia á proba da base de datos.

postgres=# c test1;

Creamos a táboa indexing_table.

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

Engadindo datos.

Comezamos a inserir datos. Agardamos 10-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

Asegúrate de facer unha copia de seguridade completa.

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

Observamos os rexistros da táboa na base de datos 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 cadea é a hora actual.

Consulta a lista de copias de seguridade completas

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

Probas de recuperación

Recuperación completa con rodar todos os WAL dispoñibles.

Detén Postgresql.

Elimina todo do cartafol /var/lib/pgsql/9.6/data.

Execute o script /usr/local/bin/backup-fetch.sh como usuario de postgres.

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

Extracción de copia de seguranza completada.

Engade recovery.conf ao cartafol /var/lib/pgsql/9.6/data co seguinte contido.

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

Iniciamos PostgreSQL. PostgreSQL iniciará o proceso de recuperación dos WAL arquivados e só entón abrirase a base de datos. 

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

Recuperación durante un tempo determinado.

Se queremos restaurar a base de datos ata un minuto determinado, engadimos o parámetro recovery_target_time a recovery.conf: indicamos a que hora restaurar a base de datos.

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

Despois da recuperación, mire a táboa 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 PostgreSQL. PostgreSQL iniciará o proceso de recuperación dos WAL arquivados e só entón abrirase a base de datos. 

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

Probas

Xerando unha base de datos de 1 GB como se describe aquí https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Solicitando o tamaño do depósito despois de xerar 1 GB de datos.

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

s4cmd é unha ferramenta de liña de comandos gratuíta para traballar con datos que residen no almacenamento de Amazon S3. A utilidade está escrita na linguaxe de programación Python e, por iso, pódese usar tanto en sistemas operativos Windows como Linux.

Instalación de 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

Comparación de resultados no gráfico.

Introdución ao sistema de copia de seguridade wal-g PostgreSQL

Como podes ver, Brotli é comparable en tamaño a LZMA, pero a copia de seguridade realízase en tempo LZ4.

Chat da comunidade de fala rusa PostgreSQL: https://t.me/pgsql

Por favor, dálle unha estrela a Github se usas wal-g

Fonte: www.habr.com

Engadir un comentario