sql >> Base de Datos >  >> RDS >> PostgreSQL

Barman Cloud – Parte 1:Archivo WAL

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

  1. barman-cli 2.10 (o superior)
  2. Cuenta Amazon AWS
  3. awscli
  4. Contenedor S3
  5. 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

    1. Instalar el repositorio público de 2ndQuadrant
    2. Instale el paquete barman-cli
      example@sqldat.com:~# apt update
example@sqldat.com:~# apt install barman-cli
    3. Instalar awscli
      example@sqldat.com:~# apt install awscli

    Configuración y configuración

    Leamos el manual:

    example@sqldat.com:~$ 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 como postgres usuario, copiando la Clave de acceso y la Clave secreta creadas previamente en la sección IAM en la consola de AWS:

    example@sqldat.com:~$ 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 el barman-cloud-wal-archive comando:

    example@sqldat.com:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001
example@sqldat.com:~$ 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 

    example@sqldat.com:~# systemctl restart example@sqldat.com

    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:

    example@sqldat.com:~$ 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:

    example@sqldat.com:~$ 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:

    example@sqldat.com:~$ createdb pg_bench_db
example@sqldat.com:~$ pgbench -i -s10 pg_bench_db

[some irrelevant output here]

example@sqldat.com:~$ 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:

    example@sqldat.com:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/
                        PRE 0000000100000000/

    Echemos un vistazo dentro del directorio 0000000100000000:

    example@sqldat.com:~$ 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.