🥇Introducción al sistema de Backup wal-g para PostgreSQL

WAL-G — una herramienta simple y efectiva para la copia de seguridad de PostgreSQL en la nube. En su funcionalidad básica, es un heredero de la popular herramienta WAL-E, pero reescrita en Go. Sin embargo, WAL-G tiene una característica nueva importante: copias delta. Las copias delta WAL-G almacenan las páginas de archivos que han cambiado desde la versión anterior de la copia de seguridad. WAL-G implementa muchas tecnologías para paralelizar las copias de seguridad. WAL-G funciona mucho más rápido que WAL-E.

Puedes leer más sobre el funcionamiento de WAL-G en el artículo: Acelerando la copia de seguridad. Charla de Yandex

El protocolo de almacenamiento S3 se ha vuelto popular para almacenar datos. Una de las ventajas de S3 es la capacidad de acceso a través de API, lo que permite organizar una interacción flexible con el almacenamiento, incluyendo acceso público de lectura, mientras que la actualización de la información en el almacenamiento solo es posible para personas autorizadas.

Existen varias implementaciones tanto abiertas como privadas de almacenes que funcionan con el protocolo S3. Hoy revisaremos una solución popular para la organización de pequeños almacenes: Minio.

Para probar WAL-G, se necesita un servidor PostgreSQL y Minio se utiliza como sustituto de S3.

Servidor Minio

Instalación de Minio

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

Edita AccessKey y SecretKey en /etc/minio/minio.conf

vi /etc/minio/minio.conf

Si no vas a usar nginx delante de Minio, debes cambiar

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Iniciamos Minio

systemctl start minio

Accedemos a la interfaz web de Minio http://ip-dirección-servidor-minio:9000 y creamos un bucket (por ejemplo, pg-backups).

Servidor de Bases de Datos

Compilo WAL-G en rpm (Anton Patsev). Github, Fedora COPR.

Si no tienes un sistema basado en RPM, utiliza la oficial guía para la instalación.

Junto con el binario de WAL-G en rpm, hay scripts que importan variables del archivo /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 WAL-G.

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

Verificamos la versión de WAL-G.

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

Edita /etc/wal-g.d/server-s3.conf según tus necesidades.

Los archivos de configuración y los archivos de datos utilizados por el clúster de bases de datos, tradicionalmente se almacenan juntos en el directorio de datos del clúster, que comúnmente se llama 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 # Какой метод сжатия использовать.

Al configurar WAL-G, especificas WALG_DELTA_MAX_STEPS: el número de pasos que separa el delta-backup del back-up base, y defines la política de delta-copy. Puedes hacer una copia con el último delta existente o crear un delta a partir del back-up completo original. Esto es necesario en caso de que una parte de tu base de datos cambie constantemente con los mismos datos.

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

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

Si pruebas en un solo servidor, debes reconfigurar el parámetro wal_level a archive para PostgreSQL de versión menor a 10, y a replica para versiones 10 y mayores de PostgreSQL.

wal_level = archive

Realizaremos la copia de seguridad de los archivos WAL cada 60 segundos mediante PostgreSQL. En producción tendrás un valor diferente para archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Se ejecutará el comando archive_command cada 60 segundos.

Iniciamos PostgreSQL

systemctl start postgresql-9.6

En una consola separada, revisamos los registros de PostgreSQL en busca de errores: (cambia postgresql-Wed.log por el actual).

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

Accedemos a psql.

su - postgres
psql

Creamos una base de datos en psql.

Creamos una tabla en la base de datos test1.

create database test1;

Cambiamos a la base de datos test.

postgres=# c test1;

Creamos la tabla indexing_table.

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

Añadiendo datos.

Iniciamos la inserción de datos. Esperamos 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

Asegúrate de hacer una copia de seguridad completa.

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

Vemos los registros en la tabla en la 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+

La fila representa la hora actual.

Revisamos la lista de copias de seguridad completas.

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

Prueba de recuperación

Recuperación completa aplicando todos los WAL disponibles.

Detenemos PostgreSQL.

Eliminamos todo en la carpeta /var/lib/pgsql/9.6/data.

Ejecutamos el script /usr/local/bin/backup-fetch.sh como el usuario postgres.

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

La extracción de la copia de seguridad se completó.

Agregamos recovery.conf en la carpeta /var/lib/pgsql/9.6/data con el siguiente contenido.

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

Iniciamos PostgreSQL. PostgreSQL iniciará el proceso de recuperación desde los archivos WAL archivados, y solo entonces se abrirá la base de datos.

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

Recuperación a un momento específico.

Si queremos restaurar la base de datos a un momento específico, añadimos el parámetro recovery_target_time en recovery.conf, especificando a qué hora restaurar la base de datos.

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

Después de la restauración, revisamos la tabla 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á el proceso de recuperación desde los archivos WAL archivados, y solo entonces se abrirá la base de datos.

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

Pruebas

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

Solicitamos el tamaño del bucket después de generar 1GB de datos.

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

s4cmd es una herramienta gratuita de línea de comandos para trabajar con datos almacenados en Amazon S3. La utilidad está escrita en Python, lo que permite su uso tanto en Windows como en Linux.

Instalamos s4cmd.

pip install s4cmd

LZ4

s4cmd --endpoint-url=http:\/\/ip-dirección-del-servidor-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3:\/\/pg-backups
840540822       s3:\/\/pg-backups\/wal_005\/\n840 MB en formato lz4 solo de los registros WAL

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

Tamaño del bucket S3 después del backup completo

581480085       s3:\/\/pg-backups\/basebackups_005\/\n842374424   s3:\/\/pg-backups\/wal_005\n581 MB ocupa el backup completo

LZMA

Después de generar 1GB de datos
338413694       s3:\/\/pg-backups\/wal_005\/\n338 MB de registros en formato lzma

Tiempo de generación del backup completo
time backup_push.sh
real    5m25.054s

Tamaño del bucket en S3
270310495       s3:\/\/pg-backups\/basebackups_005\/\n433485092   s3:\/\/pg-backups\/wal_005\/\n
270 MB ocupa el backup completo en formato lzma

Brotli

Después de generar 1GB de datos
459229886       s3:\/\/pg-backups\/wal_005\/\n459 MB de registros en formato brotli

Tiempo de generación del backup completo
real    0m23.408s

Tamaño del bucket en S3
312960942       s3:\/\/pg-backups\/basebackups_005\/\n459309262   s3:\/\/pg-backups\/wal_005\/\n
312 MB ocupa el backup completo en formato brotli

Comparación de los resultados en el gráfico.