Usando o Barman para recuperação de desastres do PostgreSQL

Deve haver muitas ferramentas poderosas disponíveis como opção de backup e restauração para o PostgreSQL em geral; Barman, PgBackRest, BART são para citar alguns neste contexto. O que nos chamou a atenção foi que o Barman é uma ferramenta que está acompanhando rapidamente a implantação da produção e as tendências do mercado.

Seja uma implantação baseada em docker, necessidade de armazenar backup em um armazenamento em nuvem diferente ou necessidades de arquitetura de recuperação de desastres altamente personalizáveis - o Barman é um concorrente muito forte em todos esses casos.

Este blog explora Barman com poucas suposições sobre implantação, porém em nenhum caso isso deve ser considerado apenas um conjunto de recursos possível. Barman está muito além do que podemos capturar neste blog e deve ser mais explorado se o ‘backup e restauração da instância do PostgreSQL’ for considerado.

Suposição de implantação pronta para DR

RPO=0 geralmente tem um custo - a implantação do servidor em espera síncrona geralmente atende a isso, mas afeta o TPS do servidor primário com bastante frequência.

Assim como o PostgreSQL, o Barman oferece várias opções de implantação para atender às suas necessidades quando se trata de RPO versus desempenho. Pense na simplicidade de implantação, RPO=0 ou impacto no desempenho quase nulo; Barman se encaixa em tudo.

Consideramos a implantação a seguir para estabelecer uma solução de recuperação de desastres para nossa arquitetura de backup e restauração.
Figura 1:Implantação do PostgreSQL com Barman

Existem dois sites (como em geral para locais de recuperação de desastres) - Site-X e Site-Y.

No Site-X existe:

Um servidor 'pgServer' hospedando uma instância de servidor PostgreSQL pgServer e um usuário de SO 'postgres'
- Instância do PostgreSQL também para hospedar uma função de superusuário ‘bmuser’
Um servidor 'bServer' hospedando os binários do Barman e um usuário do sistema operacional 'bmuser'

No Site-Y existe:

Um servidor 'geobServer' hospedando os binários do Barman e um usuário do sistema operacional 'bmuser'

Existem vários tipos de conexão envolvidos nesta configuração.

Entre 'bServer' e 'pgServer':
- Conectividade do plano de gerenciamento do Barman para a instância do PostgreSQL
- conectividade rsync para fazer backup de base real do Barman para a instância do PostgreSQL
- arquivamento WAL usando barman-wal-archive da instância PostgreSQL para Barman
- Transmissão WAL usando pg_receivexlog no Barman
Entre 'bServer' e 'geobserver':
- Sincronização entre servidores Barman para fornecer replicação geográfica

Conectividade em primeiro lugar

A conectividade primária necessária entre os servidores é via ssh. Para torná-lo sem senha, são usadas chaves ssh. Vamos estabelecer as chaves ssh e trocá-las.

No pgServer:

[email protected]$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

[email protected]$ ssh [email protected] "chmod 600 ~/.ssh/authorized_keys"

No bServer:

[email protected]$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

[email protected]$ ssh [email protected] "chmod 600 ~/.ssh/authorized_keys"

No geobServer:

[email protected]$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

[email protected]$ ssh [email protected] "chmod 600 ~/.ssh/authorized_keys"

Configuração da instância PostgreSQL

Existem duas coisas principais que precisamos para reconstituir uma instância postgres - O diretório base e os logs WAL/Transações gerados posteriormente. O servidor Barman os acompanha de forma inteligente. O que precisamos é garantir que os feeds adequados sejam gerados para Barman coletar esses artefatos.

Adicione as seguintes linhas ao postgresql.conf:

listen_addresses = '172.25.130.180'     #as per above deployment assumption

wal_level = replica                     #or higher 

archive_mode = on

archive_command = 'barman-wal-archive -U bmuser bserver pgserver %p'

O comando

Archive garante que quando o WAL for arquivado pela instância postgres, o utilitário barman-wal-archive o submeta ao servidor Barman. Deve-se notar que o pacote barman-cli, portanto, deve ser disponibilizado em 'pgServer'. Existe outra opção de usar o rsync se não quisermos usar o utilitário barman-wal-archive.

Adicione o seguinte a pg_hba.conf:

host     all                    all     172.25.130.186/32     md5

host     replication            all     172.25.130.186/32     md5

Basicamente está permitindo uma replicação e uma conexão normal do 'bmserver' para esta instância do postgres.

Agora é só reiniciar a instância e criar uma função de superusuário chamada bmuser:

[email protected]$ pg_ctl restart

[email protected]$ createuser -s -P bmuser

Se necessário, podemos evitar usar bmuser como superusuário também; que precisaria de privilégios atribuídos a este usuário. Para o exemplo acima, usamos bmuser como senha também. Mas isso é praticamente tudo, desde que seja necessária uma configuração de instância do PostgreSQL.

Configuração do Barman

Barman tem três componentes básicos em sua configuração:

Configuração global
Configuração no nível do servidor
Usuário que comandará o barman

No nosso caso, como o Barman é instalado usando rpm, temos nossos arquivos de configuração global armazenados em:

/etc/barman.conf

Queríamos armazenar a configuração do nível do servidor no diretório inicial do bmuser, portanto, nosso arquivo de configuração global tinha o seguinte conteúdo:

[barman]

barman_user = bmuser

configuration_files_directory = /home/bmuser/barman.d

barman_home = /home/bmuser

barman_lock_directory = /home/bmuser/run

log_file = /home/bmuser/barman.log

log_level = INFO

Configuração do servidor Barman principal

Na implantação acima, decidimos manter o servidor Barman primário no mesmo data center/site onde a instância do PostgreSQL é mantida. O benefício do mesmo é que há menos atraso e recuperação mais rápida em caso de necessidade. Escusado será dizer que também são necessárias menos computação e/ou necessidades de largura de banda de rede no servidor PostgreSQL.

Para permitir que Barman gerencie a instância do PostgreSQL no pgServer, precisamos adicionar um arquivo de configuração (chamamos pgserver.conf) com o seguinte conteúdo:

[pgserver]

description =  "Example pgserver configuration"

ssh_command = ssh [email protected]

conninfo = host=pgserver user=bmuser dbname=postgres

backup_method = rsync

reuse_backup = link

backup_options = concurrent_backup

parallel_jobs = 2

archiver = on

archiver_batch_size = 50

path_prefix = "/usr/pgsql-12/bin"



streaming_conninfo = host=pgserver user=bmuser dbname=postgres

streaming_archiver=on

create_slot = auto

E um arquivo .pgpass contendo as credenciais para bmuser na instância do PostgreSQL:

echo 'pgserver:5432:*:bmuser:bmuser' > ~/.pgpass

Para entender um pouco mais os itens de configuração importantes:

ssh_command :usado para estabelecer a conexão pela qual o rsync será feito
conninfo :String de conexão para permitir que Barman estabeleça conexão com o servidor postgres
reuse_backup :para permitir backup incremental com menos armazenamento
backup_method :método para fazer backup do diretório base
path_prefix :local onde os binários pg_receivexlog são armazenados
streaming_conninfo :string de conexão usada para transmitir WAL
create_slot :para garantir que os slots tenham sido criados pela instância do postgres

Configuração do servidor Barman passivo

A configuração de um site de replicação geográfica é bastante simples. Tudo o que precisa é de uma informação de conexão ssh sobre a qual este site de nó passivo fará a replicação.

O interessante é que esse nó passivo pode funcionar em modo de mistura; em outras palavras - eles podem atuar como servidores Barman ativos para fazer backups para sites PostgreSQL e em paralelo atuar como um site de replicação/cascata para outros servidores Barman.

Como, no nosso caso, esta instância do Barman (no Site-Y) precisa ser apenas um nó passivo, tudo o que precisamos é criar o arquivo /home/bmuser/barman.d/pgserver.conf com a seguinte configuração:

[pgserver]

description =  "Geo-replication or sync for pgserver"

primary_ssh_command = ssh [email protected]

Com a suposição de que as chaves foram trocadas e a configuração global neste nó é feita como mencionado anteriormente - estamos praticamente concluídos com a configuração.

E aqui está nosso primeiro backup e restauração

No bserver, certifique-se de que o processo em segundo plano para receber o WAL foi acionado; e depois verifique a configuração do servidor:

[email protected]$ barman cron

[email protected]$ barman check pgserver

A verificação deve estar OK para todas as subetapas. Caso contrário, consulte /home/bmuser/barman.log.

Emita o comando backup no Barman para garantir que haja um DATA base no qual o WAL possa ser aplicado:

[email protected]$ barman backup pgserver

No 'geobmserver', certifique-se de que a replicação seja feita executando os seguintes comandos:

[email protected]$ barman cron 

[email protected]$ barman list-backup pgserver

O cron deve ser inserido no arquivo crontab (se não estiver presente). Por uma questão de simplicidade, não mostrei aqui. O último comando mostrará que a pasta de backup também foi criada no geobmserver.

Agora, na instância do Postgres, vamos criar alguns dados fictícios:

[email protected]$ psql -U postgres -c "CREATE TABLE dummy_data( i INTEGER);"

[email protected]$ psql -U postgres -c "insert into dummy_data values ( generate_series (1, 1000000 ));"

A replicação do WAL da instância do PostgreSQL pode ser vista usando o comando abaixo:

[email protected]$ psql -U postgres -c "SELECT * from pg_stat_replication ;”

Para recriar uma instância no Site-Y, primeiro certifique-se de que os registros WAL sejam alternados. ou este exemplo, para criar uma recuperação limpa:

[email protected]$ barman switch-xlog --force --archive pgserver

No Site-X, vamos abrir uma instância autônoma do PostgreSQL para verificar se o backup está correto:

[email protected]$ barman cron 

barman recover --get-wal pgserver latest /tmp/data

Agora, edite os arquivos postgresql.conf e postgresql.auto.conf conforme as necessidades. A seguir, explique as alterações feitas para este exemplo:

postgresql.conf :listen_addresses comentados para usar como padrão localhost
postgresql.auto.conf :sudo bmuser removido do restore_command

Chame esses DADOS em /tmp/data e verifique a existência de seus registros.

Conclusão

Esta foi apenas a ponta de um iceberg. Barman é muito mais profundo do que isso por causa da funcionalidade que fornece - por exemplo, agindo como um standby sincronizado, scripts de gancho e assim por diante. Escusado será dizer que toda a documentação deve ser explorada para configurá-la de acordo com as necessidades do seu ambiente de produção.