Barman 2.11:barman-cloud-restore e barman-cloud-wal-restore

Graças aos novos utilitários barman-cloud-restore e barman-cloud-wal-restore introduzido no Barman 2.11 , agora é possível executar a recuperação de uma instância do PostgreSQL usando um backup completo executado anteriormente usando barman-cloud-wal-archive e barman-cloud-backup comandos. Vamos descobrir juntos como implementar isso no artigo a seguir.

Vale a pena notar que no Barman 2.11, todos os utilitários de nuvem para Barman estão agora em um pacote separado chamado barman-cli-cloud .

Requisitos

1. barman-cli-cloud pacote
2. Uma instância do PostgreSQL
3. Um bucket do AWS S3
4. Uma segunda máquina virtual onde executar a restauração

Neste artigo, testaremos barman-cli-cloud funcionalidades em uma máquina virtual com Debian Buster e PostgreSQL 12. Para seguir corretamente as instruções contidas neste artigo, também assumimos que você tenha:

configurou o Postgres para arquivar arquivos WAL em um bucket S3 existente usando barman-cloud-wal-archive
executou um backup e o enviou para o mesmo bucket do S3 por meio de barman-cloud-backup

Você pode conseguir isso facilmente seguindo as instruções contidas nestes artigos anteriores do blog:

Barman Cloud – Parte 1:Arquivo WAL
Barman Cloud – Parte 2:Backup na nuvem

Configure o servidor de recuperação

Como resultado, temos um bucket do S3 na AWS chamado barman-s3-test que já contém os arquivos WAL e backup arquivados via barman-cloud-wal-archive e barman-cloud-backup tools, agora precisamos configurar corretamente um servidor que será o host para a recuperação da instância do PostgreSQL.

1. Instale o PostgreSQL 12 do repositório oficial do PGDG

2. Instale o repositório público do 2ndQuadrant

3. Instale o barman-cli-cloud pacote:

example@sqldat.com:~# apt updateexample@sqldat.com:~# apt install barman-cli-cloud

4. Instale o awscli pacote:

example@sqldat.com:~# apt install awscli

5. Configure as credenciais da AWS com a ferramenta awscli como usuário postgres:

example@sqldat.com:~$ aws configure --profile barman-cloudAWS ID da chave de acesso [Nenhum]:AKI******************** Chave de Acesso Secreta da AWS [Nenhum ]:**************************************** Nome da região padrão [Nenhum]:eu -west-1Formato de saída padrão [Nenhum]:json

Execute o procedimento de restauração

Agora que o servidor de recuperação está configurado corretamente, estamos prontos para iniciar o procedimento de restauração.

Barman 2.11 apresenta a barman-cloud-backup-list comando que permite recuperar informações sobre os backups feitos com barman-cloud-backup :

example@sqldat.com:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12Backup ID End Time Begin Wal20200713T120856 2020-07-13 12:09:05 00000001000000000000000C

Agora estamos prontos para executar a restauração usando o barman-cloud-restore comando:

example@sqldat.com:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/ 
 Assim que a restauração terminar com sucesso, podemos verificar o conteúdo do diretório PGDATA:
 example@sqldat.com:~$ ls /var/lib/postgresql/12/main/PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.confbackup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wlogical postgresql.confmem_dyn pg_replslot pg_stat pg_tblspc pg_xact
 
 Agora, para ter certeza de que o processo de restauração funcionou corretamente, precisamos iniciar a instância recuperada do PostgreSQL e verificar se tudo funciona conforme o esperado. Este processo requer algumas etapas adicionais. 
 
 Primeiro, como estamos em um sistema Debian, precisamos copiar os arquivos que contêm a configuração do PostgreSQL no /etc/postgresql/12/main/ diretório:
 example@sqldat.com:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/example@sqldat.com:~$ cp /var/lib/postgresql /12/main/pg_hba.conf /etc/postgresql/12/main/example@sqldat.com:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/ 
 Segundo, crie o recovery.signal Arquivo:
 example@sqldat.com:~$ touch /var/lib/postgresql/12/main/recovery.signal
 
 Em seguida, desative o archive_command para evitar que a instância recuperada grave no mesmo bucket que a instância original:
 example@sqldat.com:~$ echo \"archive_command ='cd .'\">> /etc/postgresql/12/main/postgresql.conf
 
 Depois disso, você precisa configurar o PostgreSQL para recuperar os arquivos WAL da última linha do tempo disponível do bucket do S3 usando o barman-cloud-wal-restore no restore_command :
 example@sqldat.com:~$ echo \"restore_command ='barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\">> / etc/postgresql/12/main/postgresql.confexample@sqldat.com:~$ echo \"recovery_target_timeline ='latest'\">> /etc/postgresql/12/main/postgresql.conf
 
 IMPORTANTE :Antes de continuar, verifique se a instância do PostgreSQL não está em execução e se o diretório de destino (o diretório de dados padrão do PostgreSQL) está vazio. 
 
 Finalmente, estamos prontos para iniciar a nova instância recuperada:
 example@sqldat.com:~# systemctl restart example@sqldat.com
 
 Excelente! Como podemos ver no log do PostgreSQL, os arquivos WAL são recuperados do bucket do S3 e a instância foi iniciada corretamente:
 example@sqldat.com:~$ less /var/log/postgresql/postgresql-12-main.log...2020-07-13 12:43:25.093 UTC [9458] LOG:iniciando PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) em x86_64-pc-linux-gnu, compilado por gcc (Debian 8.3.0-6) 8.3.0, 64-bit2020-07-13 12:43:25.093 UTC [9458] LOG:escutando no endereço IPv4 "127.0.0.1", porta 54322020-07-13 12:43:25.095 UTC [9458] LOG:escutando no soquete Unix "/var/run/postgresql/.s.PGSQL.5432"2020-07- 13 12:43:25.111 UTC [9459] LOG:sistema de banco de dados foi interrompido; último conhecido em 2020-07-13 12:08:56 UTC2020-07-13 12:43:25.508 UTC [9459] LOG:iniciando a recuperação do arquivo2020-07-13 12:43:26.010 UTC [9459] LOG:log restaurado arquivo "00000001000000000000000C" do archive2020-07-13 12:43:26.052 UTC [9459] LOG:refazer começa em 0/C0000282020-07-13 12:43:26.054 UTC [9459] LOG:estado de recuperação consistente alcançado em 0/C000138200 -07-13 12:43:26.054 UTC [9458] LOG:o sistema de banco de dados está pronto para aceitar conexões somente leitura2020-07-13 12:43:26.469 UTC [9459] LOG:arquivo de log restaurado "00000001000000000000000D" do arquivo2020-07- 13 12:43:26.823 UTC [9459] LOG:refazer feito em 0/D0001B02020-07-13 12:43:27.242 UTC [9459] LOG:arquivo de log restaurado "00000001000000000000000D" do arquivo2020-07-13 12:43:27.59.59. UTC [9459] LOG:nova linha de tempo selecionada ID:22020-07-13 12:43:27.644 UTC [9459] LOG:recuperação de arquivo concluída2020-07-13 12:43:27.979 UTC [9458] LOG:o sistema de banco de dados está pronto para aceitar conexões
 Conclusão
 
 Como de costume em qualquer nova versão do Barman, recomendamos que todos atualizem seus sistemas para a versão mais recente. Uma lista completa de alterações e correções de bugs está disponível aqui. 
 
 Observe que, se você já estiver usando barman-cloud-wal-archive ou barman-cloud-backup instalado via pacote RPM/Apt e você está atualizando seu sistema, você deve instalar o barman-cli-cloud pacote. Isso se deve ao fato de que, com a versão Barman 2.11, todas as ferramentas relacionadas à nuvem fazem parte do barman-cli-cloud pacote conforme explicado no início do artigo. 
 
 As próximas versões do Barman podem melhorar os recursos de usabilidade e automação do comando de recuperação, por exemplo, preparando um recovery.conf ou recovery.signal arquivo como o Barman real faz.