PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Barman Cloud - Parte 1:Arquivo WAL

Preâmbulo


Quantos usuários atuais do Barman pensaram em salvar backups em um destino remoto na nuvem? Quantos já pensaram em fazer esse backup direto do próprio servidor PostgreSQL?

Bem, desde o Barman 2.10 isso agora é possível!
Como?
Vamos descobrir isso juntos nos artigos a seguir.

Requisitos


Os dois artigos a seguir são uma introdução prática ao novo barman-cloud-wal-archive e barman-cloud-backup ferramentas adicionadas no barman-cli package.
A primeira parte cobrirá o barman-cloud-wal-archive comando enquanto o segundo cobrirá o barman-cloud-backup command.
Os leitores precisam de um conhecimento básico dos métodos de arquivamento e backup do PostgreSQL WAL e do Barman. Também é recomendável que você conheça as tecnologias de nuvem para soluções de armazenamento como o Amazon S3.

Arquivo WAL


O Barman atuou como um arquivo WAL remoto por muitos anos, e o pacote Barman CLI foi projetado para estender a confiabilidade e a robustez do arquivamento no lado do PostgreSQL. Na verdade barman-cli fornece scripts como barman-wal-restore permitindo que um nó em espera restaure arquivos WAL de forma inteligente e segura de um arquivo Barman por meio do restore_command parâmetro no postgresql.auto.conf arquivo (ou recovery.conf até o PostgreSQL 12) e barman-wal-archive para arquivar arquivos WAL de um nó mestre para Barman por meio do archive_command parâmetro configurado no postgresql.conf Arquivo.

Arquivo do Cloud WAL


Graças ao feedback dos usuários, os desenvolvedores do Barman introduziram duas novas ferramentas na versão 2.10 :
  • barman-cloud-wal-archive
  • barman-cloud-backup

A versão 2.11 incluirá duas ferramentas adicionais para recuperação, chamadas barman-cloud-wal-restore e barman-cloud-restore .
Esta postagem é inteiramente dedicada a barman-cloud-wal-archive , que pode armazenar arquivos WAL na nuvem, permitindo o arquivamento em várias camadas com o Barman e expandindo a política de retenção de backups.
Na verdade, barman-cloud-wal-archive pode ser usado como um script de gancho configurando o pre_archive_retry_script parâmetro no Barman, para copiar arquivos WAL no armazenamento em nuvem configurado, aumentando a redundância do arquivo e possibilitando a escolha de uma política de retenção mais longa que a do Barman.

Isso não é tudo!

barman-cloud-wal-archive pode substituir o barman-wal-archive comando no archive_command parâmetro, para arquivar diretamente os arquivos WAL na nuvem, em vez de copiá-los no servidor Barman. Dessa forma, mesmo um cluster PostgreSQL que não tenha um servidor de backup dedicado separado pode contar com o serviço de armazenamento remoto para arquivar arquivos WAL.

Como funciona?


As instruções a seguir são apenas para instalar e configurar o barman-cloud-wal-archive como o archive_command no PostgreSQL.
Primeiro, decida onde arquivar os arquivos WAL. Neste artigo, usaremos o Amazon S3, que, no momento da escrita, é a única tecnologia suportada. Embora outras tecnologias que suportam API do tipo S3 (Google Cloud, DigitalOcean, Microsoft Azure, etc.) possam funcionar com a biblioteca boto3, elas ainda não foram testadas.

Requisitos

  1. barman-cli 2.10 (ou superior)
  2. Conta Amazon AWS
  3. awscli
  4. Intervalo S3
  5. Uma instância do PostgreSQL

Neste artigo vamos testar a Barman CLI em uma máquina virtual com Debian Buster e PostgreSQL 12 que já está em funcionamento.

Instalação

    1. Instale o repositório público do 2ndQuadrant
    2. Instale o pacote barman-cli
      [email protected]:~# apt update
      [email protected]:~# apt install barman-cli
    3. Instalar awscli
      [email protected]:~# apt install awscli

    Configuração e configuração


    Vamos ler o manual:
    [email protected]:~$ 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').
    [...]
    

    Portanto, para usá-lo corretamente, basta configurar as credenciais da AWS com o awscli ferramenta como o postgres usuário, copiando a chave de acesso e a chave secreta criadas anteriormente na seção do IAM no console da AWS:
    [email protected]:~$ 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
    

    Certifique-se de ter um bucket do S3 disponível na AWS. Eu escolhi chamá-lo de barman-s3-test para deixar claro.
    Devemos poder agora testar o barman-cloud-wal-archive comando:
    [email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001
    [email protected]:~$ echo $?
    0
    

    O status de saída confirma que o comando foi bem-sucedido. Agora podemos adicionar a seguinte linha na parte inferior do arquivo de configuração do PostgreSQL e reiniciar a instância:
    archive_mode = on
    [email protected]:~# systemctl restart [email protected]
    

    Como nossos dados serão copiados em um armazenamento remoto, fora de nosso controle, é importante armazená-los compactados e criptografado . O barman-cloud-wal-archive O comando suporta dois métodos diferentes de compactação:
    [email protected]:~$ 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'
    [...]
    

    A opção de criptografia apenas informará ao bucket do S3 qual método usar para armazenar os dados criptografados. Os dados criptografados não podem ser lidos por nenhum outro usuário da AWS, exceto pelo proprietário do bucket. A nuvem Barman não criptografa nenhum objeto antes de enviá-lo ao S3, apenas solicita ao bucket para armazená-los criptografados se o S3 tiver sido configurado corretamente. No entanto, todas as conexões com o S3 são estabelecidas com segurança por meio de https .

    Vamos adicionar a seguinte linha na parte inferior do postgresql.conf Arquivo:

    archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'

    Desta vez, basta recarregar a configuração para aplicar as novas alterações:
    [email protected]:~$ psql -c “SELECT pg_reload_conf()”
    

    Para testar se o novo archive_command está funcionando, o PostgreSQL deve produzir arquivos WAL para serem arquivados, portanto, temos que fazer algum tráfego com a ajuda do pgbench ferramenta:
    [email protected]:~$ createdb pg_bench_db
    [email protected]:~$ pgbench -i -s10 pg_bench_db
    
    [some irrelevant output here]
    
    [email protected]:~$ 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)
    

    Neste ponto, devemos ver os arquivos WAL arquivados no bucket do S3. Vamos verificar, construindo o caminho de destino com o nome do servidor e o diretório de destino WAL:
    [email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/
                            PRE 0000000100000000/
    

    Vamos dar uma olhada dentro do diretório 0000000100000000:
    [email protected]:~$ 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
    

    Excelente!

    Os arquivos WAL estão sendo compactados antes de serem carregados no bucket do S3 e são armazenados criptografados, economizando espaço (e dinheiro) e aumentando o nível de segurança de nossos dados.

    Conclusões


    O barman-cloud-wal-archive comando é o que os usuários esperaram por muito tempo.

    Se você é um daqueles que usou pre_archive_retry_script para implementar um script personalizado para fazer upload de arquivos WAL para um bucket do S3, isso pode ser usado como um substituto melhor porque é desenvolvido e mantido por desenvolvedores da Barman e é testado e entregue pelo sistema de entrega contínua do 2ndQuadrant.

    Caso você ainda não tenha pensado nisso, isso abre novas políticas de retenção que podem ser mais longas para armazenamento em nuvem do que as locais Barman, aumentando a idade dos objetos na nuvem, economizando espaço no armazenamento local, definindo corretamente uma política de retenção mais longa na configuração dos buckets do S3.

    Caso contrário, ele pode ser usado como fizemos neste artigo, para arquivar arquivos WAL diretamente do servidor PostgreSQL. Embora isso remova uma etapa intermediária, o RPO aumenta em comparação com o método de streaming, pois o PostgreSQL arquivará o arquivo WAL somente após tê-lo fechado. Portanto, em caso de problemas no nó PostgreSQL, podemos perder algumas alterações. Quando possível, recomendamos implementar esse método junto com o streaming para um servidor Barman para alcançar RPO=0 (com streaming síncrono).

    Agora que temos um sistema de arquivamento contínuo, podemos fazer nosso primeiro backup em nuvem usando o barman-cloud-backup ferramenta.

    Vejo você na segunda parte do artigo.