Familiaridade com pg_probackup. Primeira parte

Olá, sou Alexander Nikitin, administrador-chefe de sistema do BARS Group. Neste artigo, quero apresentar a ferramenta pg_probackup .



Pg_probackup é um desenvolvimento do Postgres Professional que ajuda a fazer cópias de backup do DBMS PostgreSQL. Ao contrário do utilitário pg_basebackup padrão, esta ferramenta permite criar backups incrementais no nível do bloco de dados (8Kb por padrão), validar backups e DBMS, definir políticas de armazenamento e muito mais.



Neste artigo, não pretendo descrever todos os aspectos possíveis de se trabalhar com o pg_probackup, apenas quero dar uma ideia de como você pode usar esta ferramenta em seu trabalho.



Os seguintes casos de uso serão considerados:

• wal-

1

Dado: Temos dois servidores (OS CentOS 7), no primeiro temos nosso banco de dados (hostname srv_db1, usuário postgres, PostgreSQL 12.4 está instalado), e no segundo iremos armazenar backups (hostname srv_bkp, usuário backup_user).

Você deve configurar o backup para que as cópias do cluster PostgreSQL sejam armazenadas no servidor srv_bkp.



Solução: o

pg_probackup pode funcionar via ssh, iniciando agentes em um host remoto que usa uma conexão ssh como canal de comunicação e transporte. Da mesma forma, você precisa ter certeza de que o backup_user no host srv_bkp pode se conectar ao usuário postgres no host srv_db1.



1) Conecte-se a srv_bkp com backup_user e execute os seguintes comandos:

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

Ative o modo paranóico e edite o arquivo ~ / .ssh / authorized_keys no servidor srv_db1

Antes da linha com as chaves, insira o seguinte:

command="pg_probackup-12 agent"

Então você deve acabar com algo assim:

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

Com isso, dizemos que nada além do "agente pg_probackup-12" pode ser iniciado via SSH (você pode ler mais sobre isso aqui ).



2) Instalamos o pg_probackup em ambas as máquinas (no exemplo, estamos trabalhando no CentOS, mas para outras distribuições o processo de instalação está descrito na documentação ):

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

A última versão disponível do pg_probackup será instalada, no momento da redação deste artigo - 2.4.2.



3) crie um alias em srv_bkp (não é necessário, mas é mais conveniente) e defina uma variável contendo o caminho para o diretório com backups (após criar este diretório):

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

carregue o perfil

. .bash_profile

4) em srv_bkp, inicialize o diretório de backup e adicione uma nova instância:

pg_probackup init

Adicione a instância PostgreSQL ao diretório, dê a ela o nome db1, especifique os parâmetros de conexão ssh - host, nome de usuário e caminho para PGDATA.

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

Se a linha aparecer

INFO: Instance 'db1' successfully inited

Portanto, a inicialização foi bem-sucedida.

Vamos definir uma política de retenção de backups:

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

A política resultante se resume ao seguinte:



é necessário manter todos os backups com menos de 7 dias,

enquanto o número de backups completos deve ser de pelo menos dois



5) Para criar backups, você precisa se conectar a um DBMS, então criamos um banco de dados no cluster PostgreSQL ao qual a conexão ocorrerá para gerenciar o processo de backup (do ponto de vista da segurança, isso é melhor do que conectar-se a um banco de dados do produto), e também alterar os parâmetros do banco de dados:

$ createdb backupdb

juntando-se a um novo banco de dados

psql -d backupdb

crie uma função de banco de dados em nome da qual o processo de backup será gerenciado:

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;

Vamos prestar atenção ao parâmetro listen_addresses:

show listen_addresses;

se for localhost, mude para *

alter system set listen_addresses='*';

Se você alterou listen_addresses, o PostgreSQL deve ser reiniciado.



Vamos ver onde localizamos o arquivo pg_hba.conf

psql –c 'show hba_file'

Adicione as seguintes regras a pg_hba.conf:

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

Nós relemos a configuração:

psql -c 'select pg_reload_conf()'

Verificamos se houve algum erro de digitação:

psql -c 'select * from pg_hba_file_rules'

Em srv_bkp, no diretório home do usuário backup_user, crie um arquivo no qual gravamos o nome do servidor ou seu endereço IP, porta, nome do banco de dados, nome de usuário e senha. Este arquivo é necessário para que a senha seja inserida automaticamente ao criar uma cópia de backup.

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

Defina os direitos de acesso necessários para este arquivo

chmod 600 ~/.pgpass

E crie o primeiro backup:

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

Se fizermos tudo corretamente, algo assim aparecerá na tela:

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 atenção ao aviso emitido por pg_probackup - a verificação de soma de verificação não está habilitada em nosso cluster, portanto, ele não pode verificar se os blocos de dados estão corretos. Em outras palavras, você não está protegido do fato de que blocos de dados inválidos não entrem no backup.



Vamos ver as configurações atuais:

pg_probackup show-config --instance db1

Agora vamos encurtar o comando para criar backups - vamos escrever alguns dos parâmetros para a configuração da instância 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

Vamos comparar: como era e como se tornou

pg_probackup show-config --instance db1

Vamos fazer uma cópia incremental no modo DELTA sem especificar os parâmetros definidos na configuração:

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

Vamos ver o que temos

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 

São muitas informações, uma descrição detalhada pode ser encontrada na documentação , no entanto, vamos nos alongar em alguns pontos:



Tempo de recuperação - o tempo mínimo pelo qual você pode recuperar usando este



modo de backup - o modo em que a cópia foi feita, atualmente 4 estão disponíveis modos - um completo (FULL) e três incrementais (PAGE, DELTA e PTRACK)



Modo WAL- as seguintes opções são possíveis aqui - STREAM e ARCHIVE. As cópias criadas no modo STREAM contêm todos os arquivos necessários para restaurar para um estado WAL consistente. Apenas para que este modo funcionasse, foi necessário atribuir a função REPLICATION ao nosso usuário de backup. O modo ARQUIVO assume que configuramos o arquivamento do WAL e, em seguida, os arquivos WAL necessários estarão localizados no caminho conhecido para pg_probackup.



Status - há muitos status, todos eles são descritos na documentação, mas se virmos algo diferente de OK, então faz sentido ir para a documentação e ver o que deu errado.



Como você deve ter adivinhado, podemos analisar a saída do comando pg_probackup show e obter o status do último backup feito, processá-lo e enviá-lo ao sistema de monitoramento, e lá já podemos configurar as regras pelas quais a notificação dos funcionários responsáveis ​​pelo SGBD será acionada.



Vamos criar um script bkp_base.sh que iniciará o backup e enviará o resultado ao sistema de monitoramento:

#! /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

Escrevemos uma chamada para o script resultante no crontab, por exemplo, você pode definir a seguinte programação:

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

Isso completa a solução da primeira tarefa - configuramos o backup, definimos a política de retenção de cópias. Também enviamos o status dos backups para o sistema de monitoramento.



Na próxima parte, veremos como criar um arquivo wal e backups de arquivo.