Familiaridad con pg_probackup. Primera parte

Hola, soy Alexander Nikitin, administrador jefe de sistemas de BARS Group. En este artículo, quiero presentarle la herramienta pg_probackup .



Pg_probackup es un desarrollo de Postgres Professional que ayuda a realizar copias de seguridad de PostgreSQL DBMS. A diferencia de la utilidad pg_basebackup estándar, esta herramienta le permite crear copias de seguridad incrementales a nivel de bloque de datos (8 Kb por defecto), validar copias de seguridad y DBMS, establecer políticas de almacenamiento y mucho más.



En este artículo, no pretendo describir todos los aspectos posibles de trabajar con pg_probackup, solo quiero dar una idea de cómo puede utilizar esta herramienta en su trabajo.



Se considerarán los siguientes casos de uso:

• wal-

1

Dado: Tenemos dos servidores (OS CentOS 7), en el primero tenemos nuestra base de datos (nombre de host srv_db1, usuario postgres, PostgreSQL 12.4 está instalado), y en el segundo almacenaremos copias de seguridad (nombre de host srv_bkp, usuario backup_user).

Debe configurar la copia de seguridad para que las copias del clúster de PostgreSQL se almacenen en el servidor srv_bkp.



Solución:

pg_probackup puede funcionar a través de ssh, lanzando agentes en un host remoto que usa una conexión ssh como canal de comunicación y transporte. En consecuencia, debe asegurarse de que backup_user en el host srv_bkp pueda conectarse al usuario de postgres en el host srv_db1.



1) Conéctese a srv_bkp con backup_user y ejecute los siguientes comandos:

ssh-keygen -t rsa
ssh-copy-id postgres@srv_db1

Active el modo paranoico y edite el archivo ~ / .ssh / authorized_keys en el servidor srv_db1

Antes de la línea con las claves, inserte lo siguiente:

command="pg_probackup-12 agent"

Entonces deberías terminar con algo como esto:

command="pg_probackup-12 agent" ssh-rsa AAAA....

Con esto decimos que nada más que el "agente pg_probackup-12" se puede iniciar a través de SSH (puede leer más sobre esto aquí ).



2) Instalamos pg_probackup en ambas máquinas (en el ejemplo estamos trabajando en CentOS, pero para otras distribuciones el proceso de instalación se describe en la documentación ):

yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
rpm -ivh https://repo.postgrespro.ru/pg_probackup/keys/pg_probackup-repo-centos.noarch.rpm
yum install pg_probackup-12
yum install pg_probackup-12-debuginfo

Se instalará la última versión disponible de pg_probackup, en el momento de escribir este artículo: 2.4.2.



3) cree un alias en srv_bkp (esto no es necesario, pero es más conveniente) y defina una variable que contenga la ruta al directorio con copias de seguridad (después de crear este directorio):

mkdir /home/backup_user/backup_db
echo "BACKUP_PATH=/home/backup_user/backup_db">>~/.bash_profile
echo "export BACKUP_PATH">>~/.bash_profile
echo "alias pg_probackup='pg_probackup-12'">>~/.bash_profile

cargar el perfil

. .bash_profile

4) en srv_bkp, inicialice el directorio de respaldo y agregue una nueva instancia:

pg_probackup init

Agregue la instancia de PostgreSQL al directorio, asígnele el nombre db1, especifique los parámetros de conexión ssh: host, nombre de usuario y ruta a PGDATA.

pg_probackup add-instance --instance=db1 --remote-host=srv_db1 --remote-user=postgres --pgdata=/var/lib/pgsql/12/data

Si aparece la línea

INFO: Instance 'db1' successfully inited

Entonces la inicialización fue exitosa.

Definamos una política para la retención de copias de seguridad:

pg_probackup set-config --instance db1 --retention-window=7 --retention-redundancy=2

La política resultante se reduce a lo siguiente:



es necesario mantener todas las copias de seguridad en menos de 7 días,

mientras que la cantidad de copias de seguridad completas debe ser de al menos dos



5) Para crear copias de seguridad, debe conectarse a un DBMS, por lo que creamos una base de datos en el clúster de PostgreSQL al que se producirá la conexión para gestionar el proceso de copia de seguridad (desde el punto de vista de la seguridad, esto es mejor que conectarse a una base de datos de productos), y también cambiar los parámetros de la base de datos:

$ createdb backupdb

unirse a una nueva base de datos

psql -d backupdb

Cree un rol de base de datos en nombre del cual se administrará el proceso de respaldo:

BEGIN;
CREATE ROLE backup WITH LOGIN REPLICATION password 'Strong_PWD';
GRANT USAGE ON SCHEMA pg_catalog TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO backup;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO backup;
COMMIT;

Prestemos atención al parámetro listen_addresses:

show listen_addresses;

si localhost, cambie a *

alter system set listen_addresses='*';

Si cambió listen_addresses, debe reiniciar PostgreSQL.



Veamos dónde hemos ubicado el archivo pg_hba.conf

psql –c 'show hba_file'

Agregue las siguientes reglas a pg_hba.conf:

# pg_probackup access permission
host    backupdb   backup          srv_bkp        md5
host    replication  backup          srv_bkp        md5

Volvemos a leer la configuración:

psql -c 'select pg_reload_conf()'

Verificamos si hubo errores tipográficos:

psql -c 'select * from pg_hba_file_rules'

En srv_bkp, en el directorio de inicio del usuario backup_user, creamos un archivo en el que escribimos el nombre del servidor o su dirección IP, puerto, nombre de la base de datos, nombre de usuario y contraseña. Este archivo es necesario para que la contraseña se ingrese automáticamente al crear una copia de seguridad.

echo "srv_db1:5432:replication:backup:Strong_PWD">>~/.pgpass
echo "srv_db1:5432:backupdb:backup:Strong_PWD">>~/.pgpass

Establezca los derechos de acceso necesarios a este archivo

chmod 600 ~/.pgpass

Y crea la primera copia de seguridad:

pg_probackup backup --instance=db1 -j2 --backup-mode=FULL --compress --stream --delete-expired --pguser=backup --pgdatabase=backupdb --remote-host=srv_db1 --remote-user=postgres

Si hicimos todo correctamente, aparecerá algo como esto en la pantalla:

INFO: Backup start, pg_probackup version: 2.4.2, instance: db1, backup ID: QFERC9, backup mode: FULL, wal mode: STREAM, remote: true, compress-algorithm: zlib, compress-level: 1
WARNING: This PostgreSQL instance was initialized without data block checksums. pg_probackup have no way to detect data block corruption without them. Reinitialize PGDATA with option '--data-checksums'.
INFO: PGDATA size: 3373MB
INFO: Start transferring data files
INFO: Data files are transferred, time elapsed: 1m:0s
INFO: wait for pg_stop_backup()
INFO: pg_stop backup() successfully executed
INFO: Syncing backup files to disk
INFO: Backup files are synced, time elapsed: 1s
INFO: Validating backup QFERC9
INFO: Backup QFERC9 data files are valid
INFO: Backup QFERC9 resident size: 975MB
INFO: Backup QFERC9 completed
INFO: Evaluate backups by retention
INFO: Backup QFERC9, mode: FULL, status: OK. Redundancy: 1/2, Time Window: 0d/7d. Active
INFO: There are no backups to merge by retention policy
INFO: There are no backups to delete by retention policy
INFO: There is no WAL to purge by retention policy

Preste atención a la advertencia emitida por pg_probackup: la verificación de la suma de verificación no está habilitada en nuestro clúster, por lo que no puede verificar la corrección de los bloques de datos. En otras palabras, no está protegido del hecho de que los bloques de datos defectuosos no entren en la copia de seguridad.



Veamos la configuración actual:

pg_probackup show-config --instance db1

Ahora acortemos el comando para crear copias de seguridad; escribiremos algunos de los parámetros en la configuración de la instancia db1:

pg_probackup set-config --instance=db1 --remote-host=srv_db1 --remote-user=postgres --pguser=backup --pgdatabase=backupdb --log-filename=backup_cron.log --log-level-file=log --log-directory=/home/backup_user/backup_db/log

Comparemos: cómo fue y cómo se convirtió

pg_probackup show-config --instance db1

Hagamos una copia incremental en modo DELTA sin especificar los parámetros establecidos en la configuración:

pg_probackup backup --instance=db1 -j2 --progress -b DELTA --compress --stream --delete-expired

Veamos que tenemos

BACKUP INSTANCE 'db1'
=====================================================================================================================================
 Instance  Version  ID      Recovery Time           Mode   WAL Mode  TLI   Time   Data   WAL  Zratio  Start LSN   Stop LSN    Status
=====================================================================================================================================
 db1       12       QFERKZ  2020-08-21 05:55:52-04  DELTA  STREAM    1/1     9s  136kB  32MB    1.00  0/B0000028  0/B0000168  OK
 db1       12       QFERC9  2020-08-21 05:51:34-04  FULL   STREAM    1/0  1m:3s  959MB  16MB    3.52  0/AE000028  0/AE0001A0  OK 

Hay mucha información, se puede encontrar una descripción detallada en la documentación , sin embargo, detengámonos en algunos puntos:



Tiempo de recuperación : el tiempo mínimo durante el cual puede recuperarse usando este



Modo de copia de seguridad : el modo en el que se realizó la copia, actualmente 4 están disponibles modos: uno completo (FULL) y tres incrementales (PAGE, DELTA y PTRACK)



Modo WAL- Las siguientes opciones son posibles aquí - STREAM y ARCHIVE. Las copias creadas en modo STREAM contienen todos los archivos necesarios para la recuperación a un estado WAL consistente. Solo para que este modo funcione, fue necesario otorgar el rol de REPLICACIÓN a nuestro usuario de respaldo. El modo ARCHIVE asume que hemos configurado el archivo WAL, y luego los archivos WAL necesarios se ubicarán en la ruta conocida para pg_probackup.



Estado : hay muchos estados, todos se describen en la documentación, pero si vemos algo diferente de OK, entonces tiene sentido ir a la documentación y ver qué salió mal.



Como habrás adivinado, podemos analizar la salida del comando pg_probackup show y obtener el estado de la última copia de seguridad realizada, procesarla y enviarla al sistema de monitoreo, y allí ya podemos configurar las reglas por las que se disparará la notificación de los empleados responsables del DBMS.



Creemos un script bkp_base.sh que iniciará la copia de seguridad y enviará el resultado al sistema de monitoreo:

#! /bin/sh
#    
. /home/backup_user/.bash_profile
#    ,        (FULL, DELTA  ..)
pg_probackup backup --instance=db1 -j 2 --progress -b $1 --compress --stream --delete-expired 
#         zabbix.
if [ "$(pg_probackup show --instance=db1 --format=json | jq -c '.[].backups[0].status')" == '"OK"' ]; then
  result=0;
else
  result=1;
fi
#  zabbix        zabbix_trapper   pg.db_backup
#         ,      ,  ,         .
/opt/zabbix/bin/zabbix_sender -c /opt/zabbix/etc/pg.zabbix_agentd.conf -k pg.db_backup -o $result

Escribimos una llamada al script resultante en crontab, por ejemplo, puede establecer el siguiente horario:

00 01 * * 7 /home/backup_user/scr/bkp_base.sh FULL
00 01 * * 1,2,3,4,5,6 /home/backup_user/scr/bkp_base.sh DELTA

Esto completa la solución de la primera tarea: hemos configurado la copia de seguridad, definido la política de retención de copias. También enviamos el estado de las copias de seguridad al sistema de monitoreo.



En la siguiente parte, veremos cómo crear un archivo de archivo wal y crear copias de seguridad de archivos.