Preámbulo
¿Cuántos usuarios actuales de Barman han pensado en guardar copias de seguridad en un destino remoto en la nube? ¿Cuántos han pensado en tomar esa copia de seguridad directamente desde el propio servidor PostgreSQL?
Pues desde Barman 2.10 ¡esto ahora es posible!
¿Cómo?
Vamos a descubrirlo juntos en los siguientes artículos.
Requisitos
Los siguientes dos artículos pretenden ser una introducción práctica al nuevo barman-cloud-wal-archive
y barman-cloud-backup
herramientas agregadas en el barman-cli
paquete.
La primera parte cubrirá el barman-cloud-wal-archive
comando mientras que el segundo cubrirá el barman-cloud-backup
comando.
Los lectores necesitan un conocimiento básico de los métodos de copia de seguridad y archivado WAL de PostgreSQL, y Barman. También se recomienda que conozca las tecnologías de nube para soluciones de almacenamiento como Amazon S3.
Archivo WAL
Barman ha actuado como un archivo WAL remoto durante muchos años, y el paquete de la CLI de Barman se ha diseñado para ampliar la confiabilidad y solidez del archivo en el lado de PostgreSQL. De hecho barman-cli
proporciona scripts como barman-wal-restore
permitiendo que un nodo en espera restaure de manera inteligente y segura archivos WAL desde un archivo de Barman a través del restore_command
parámetro en el postgresql.auto.conf
archivo (o recovery.conf
file hasta PostgreSQL 12), y barman-wal-archive
para archivar archivos WAL desde un nodo maestro a Barman a través del archive_command
parámetro configurado en el postgresql.conf
archivo.
Archivo WAL en la nube
Gracias a los comentarios de los usuarios, los desarrolladores de Barman han introducido dos nuevas herramientas en la versión 2.10 :
barman-cloud-wal-archive
barman-cloud-backup
La versión 2.11 incluirá dos herramientas adicionales para la recuperación, llamadas barman-cloud-wal-restore
y barman-cloud-restore
.
Esta publicación está completamente dedicada a barman-cloud-wal-archive
, que puede almacenar archivos WAL en la nube, lo que permite el archivado de varios niveles con Barman y amplía la política de retención de copias de seguridad.
De hecho, barman-cloud-wal-archive
se puede usar como script de gancho configurando el pre_archive_retry_script
parámetro en Barman, para copiar archivos WAL en el almacenamiento en la nube configurado, aumentando la redundancia del archivo y haciendo posible elegir una política de retención más larga que la de Barman.
¡Eso no es todo!
barman-cloud-wal-archive
puede reemplazar el barman-wal-archive
comando en el archive_command
parámetro, para archivar directamente archivos WAL en la nube, en lugar de copiarlos en el servidor Barman. De esta manera, incluso un clúster de PostgreSQL que no tenga un servidor de respaldo dedicado separado puede confiar en el servicio de almacenamiento remoto para archivar archivos WAL.
¿Cómo funciona?
Las siguientes instrucciones son solo para instalar y configurar barman-cloud-wal-archive
como archive_command
en PostgreSQL.
Primero, decida dónde archivar los archivos WAL. En este artículo utilizaremos Amazon S3, que, en el momento de escribir este artículo, es la única tecnología compatible. Aunque otras tecnologías que admiten API similares a S3 (Google Cloud, DigitalOcean, Microsoft Azure, etc.) pueden funcionar con la biblioteca boto3, aún no se han probado.
Requisitos
- barman-cli 2.10 (o superior)
- Cuenta Amazon AWS
- awscli
- Contenedor S3
- Una instancia de PostgreSQL
En este artículo probaremos Barman CLI en una máquina virtual con Debian Buster y PostgreSQL 12 que ya está funcionando.
Instalación
-
- Instalar el repositorio público de 2ndQuadrant
- Instale el paquete barman-cli
[email protected]:~# apt update [email protected]:~# apt install barman-cli
- Instalar awscli
[email protected]:~# apt install awscli
Configuración y configuración
Leamos el manual:
[email protected]:~$ man barman-cloud-wal-archive [...] SYNOPSIS barman-cloud-wal-archive [OPTIONS] DESTINATION_URL SERVER_NAME WAL_PATH [...] POSITIONAL ARGUMENTS DESTINATION_URL URL of the cloud destination, such as a bucket in AWS S3. For example: s3://BUCKET_NAME/path/to/folder (where BUCKET_NAME is the bucket you have created in AWS). SERVER_NAME the name of the server as configured in Barman. WAL_PATH the value of the `%p' keyword (according to `archive_command'). [...]
Entonces, para usarlo correctamente, solo necesitamos configurar las credenciales de AWS con el
awscli
herramienta comopostgres
usuario, copiando la Clave de acceso y la Clave secreta creadas previamente en la sección IAM en la consola de AWS:[email protected]:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
Asegúrese de tener un depósito S3 disponible en AWS. Elegí llamarlo
barman-s3-test
para dejarlo claro.
Ahora deberíamos poder probar elbarman-cloud-wal-archive
comando:[email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001 [email protected]:~$ echo $? 0
El estado de salida confirma que el comando tuvo éxito. Ahora podemos agregar la siguiente línea al final del archivo de configuración de PostgreSQL y reiniciar la instancia:
archive_mode = on
[email protected]:~# systemctl restart [email protected]
Dado que nuestros datos se copiarán en un almacenamiento remoto, fuera de nuestro control, es importante que los almacenemos comprimidos y cifrado . El
barman-cloud-wal-archive
El comando admite dos métodos diferentes de compresión:[email protected]:~$ barman-cloud-wal-archive --help [...] -z, --gzip gzip-compress the WAL while uploading to the cloud -j, --bzip2 bzip2-compress the WAL while uploading to the cloud -e ENCRYPTION, --encryption ENCRYPTION Enable server-side encryption for the transfer. Allowed values: 'AES256', 'aws:kms' [...]
La opción de cifrado solo informará al depósito S3 qué método usar para almacenar los datos cifrados. Los datos cifrados no pueden ser leídos por ningún otro usuario de AWS que no sea el propietario del depósito. La nube de Barman no cifra ningún objeto antes de enviarlo a S3, solo le pide al depósito que los almacene cifrados si S3 se ha configurado correctamente. Sin embargo, cualquier conexión a S3 se establece de forma segura a través de
https
.Agreguemos la siguiente línea al final del
postgresql.conf
archivo:archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'
Esta vez, solo una recarga de la configuración es suficiente para aplicar los nuevos cambios:
[email protected]:~$ psql -c “SELECT pg_reload_conf()”
Para probar si el nuevo archive_command está funcionando, PostgreSQL debería producir archivos WAL para archivar, por lo tanto, tenemos que hacer algo de tráfico con la ayuda de
pgbench
herramienta:[email protected]:~$ createdb pg_bench_db [email protected]:~$ pgbench -i -s10 pg_bench_db [some irrelevant output here] [email protected]:~$ pgbench -c 10 -j 2 -T 30 pg_bench_db starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 10 query mode: simple number of clients: 10 number of threads: 2 duration: 30 s number of transactions actually processed: 84501 latency average = 3.552 ms tps = 2815.224687 (including connections establishing) tps = 2815.427535 (excluding connections establishing)
En este punto, deberíamos ver los archivos WAL archivados en el depósito S3. Comprobémoslo, construyendo la ruta de destino con el nombre del servidor y el directorio de destino WAL:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/
Echemos un vistazo dentro del directorio 0000000100000000:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/0000000100000000/ 2020-01-08 08:20:54 1624168 000000010000000000000001.bz2 2020-01-08 08:21:00 293422 000000010000000000000002.bz2 2020-01-08 08:21:06 301934 000000010000000000000003.bz2 2020-01-08 08:21:11 295648 000000010000000000000004.bz2 2020-01-08 08:21:16 293675 000000010000000000000005.bz2 2020-01-08 08:21:21 299348 000000010000000000000006.bz2 2020-01-08 08:21:27 551249 000000010000000000000007.bz2 2020-01-08 08:21:33 976523 000000010000000000000008.bz2 2020-01-08 08:21:37 4542104 000000010000000000000009.bz2 2020-01-08 08:21:46 5052693 00000001000000000000000A.bz2
¡Genial!
Los archivos WAL se comprimen antes de cargarlos en el depósito S3 y se almacenan cifrados, lo que nos ahorra espacio (y dinero) y aumenta el nivel de seguridad de nuestros datos.
Conclusiones
El
barman-cloud-wal-archive
comando es lo que los usuarios han esperado durante mucho tiempo.Si eres de los que ha usado
pre_archive_retry_script
para implementar una secuencia de comandos personalizada para cargar archivos WAL en un depósito S3, entonces esto se puede usar como un mejor reemplazo porque lo desarrollan y mantienen los desarrolladores de Barman, y el sistema 2ndQuadrant Continuous Delivery lo prueba y entrega.En caso de que aún no lo haya pensado, esto abre nuevas políticas de retención que pueden ser más largas para el almacenamiento en la nube que las locales de Barman, lo que aumenta la antigüedad de los objetos en la nube y ahorra espacio en el almacenamiento local, configurando correctamente una política de retención más larga en la configuración de los depósitos S3.
De lo contrario, se puede usar como lo hicimos en este artículo, para archivar archivos WAL directamente desde el servidor PostgreSQL. Aunque esto elimina un paso intermedio, el RPO aumenta en comparación con el método de transmisión, porque PostgreSQL archivará el archivo WAL solo después de haberlo cerrado. Por lo tanto, en caso de problemas en el nodo de PostgreSQL, podríamos perder algunos cambios. Cuando sea posible, recomendamos implementar este método junto con la transmisión a un servidor Barman para lograr RPO=0 (con transmisión síncrona).
Ahora que contamos con un sistema de archivo continuo, podemos realizar nuestra primera copia de seguridad en la nube utilizando
barman-cloud-backup
herramienta.Nos vemos en la segunda parte del artículo.