Ferramentas de backup do PostgreSQL. Andrey Salnikov (Garça de Dados)

Sugiro que você leia a descriptografia do relatório por Andrey Salnikov do Data Egret "Ferramentas de criação de backup do PostgreSQL" . No final, uma tabela de resumo atualizada de ferramentas


Esta palestra é sobre as ferramentas de backup disponíveis do PostgreSQL. Backups lógicos, backups binários, ferramentas de backup internas e ferramentas de terceiros. São necessários backups incrementais quando podem realmente ajudar. Vamos ver quando e qual ferramenta é mais apropriada para usar. Qual é a melhor maneira de automatizar o processo de backup e verificar a integridade de um backup? Dê uma olhada em ferramentas como pg_dump , pg_basebackup , barman , wal-e , wal-g , pgbackrest , BART e pg_probackup .



Meu nome é Andrey Salnikov, sou funcionário da Data Egret e este relatório será dedicado às ferramentas para criar backups no PostgreSQL.



Primeiro sobre quem somos, minha empresa. Nossa principal atividade: trabalhamos como administradores remotos e temos um número bastante grande de clientes. Existem bases enormes, existem várias bases pequenas, existem todos os tipos de misturas quando uma base grande ou várias pequenas. Também fornecemos serviços de consultoria e auditoria - este é o caso se as pessoas não precisam de suporte constante, mas é necessário algum tipo de conhecimento.
Como o PostgreSQL é um produto de código aberto, naturalmente participaremos de todos os tipos de conferências em termos de compartilhamento de nossa experiência e de ajudar o PostgreSQL de todas as formas possíveis. Porque o banco de dados PostgreSQL é realmente bom. Acontece que vimos muitos perfis de carga: cargas DWH, cargas WEB e misturas de cargas. E as bases estavam caindo de maneiras diferentes. Muita experiência.



Esta é a parte mais interessante do relatório. Por que os backups são necessários? Na verdade, eles são necessários para que possamos descansar em paz, para que possamos dormir em paz, para que possamos sair em shows calmamente. Agora, esse é o objetivo principal, do ponto de vista da base, por que os backups são necessários. Para que tudo fique calmo em nossas vidas. Porque se houver backups verificados, podemos fazer tudo isso. Mas o que está acontecendo com a base é a décima coisa.



Qual é a gama de ferramentas para criar backups no mundo do PostgreSQL? Esta é a ferramenta de recuperação interna pg_dump, pg_dumpall ou pg_restore. Essa é a única ferramenta que permite fazer backups lógicos. Ou seja, ele pode pg_dump você, no SQL para despejar, e em um pequeno formato binário para despejar dados. E sai da caixa com o PostgreSQL.
A próxima ferramenta (pg_basebackup) para criar backups, que também sai da caixa e inicia mais com esta ferramenta, além de todas elas serão ferramentas para criar backups binários de banco de dados. Pg_basebackup também é uma ferramenta que sai da caixa, o que nos permite fazer upload de réplicas do postgreSQL e fazer uma cópia binária do banco de dados, gravar um banco de dados persistente e, se quisermos arquivar a tempo, podemos configurar o PostgreSQL para despejá-lo para algum tipo de disco. Essas são as ferramentas básicas. Eles são bons, eles fazem, eles executam sua funcionalidade em 5, mas são inconvenientes em termos de gerenciamento e algum tipo de massa. Quando você possui 20 bancos de dados, precisará fazer isso sozinho.
As próximas duas ferramentas são ferramentas específicas de nuvem pura - wal-e e wal-g. Os mesmos caras estão desenvolvendo-os, mas o desenvolvimento do wal-e acabou e eles mudaram para o wal-g. Essas ferramentas são voltadas principalmente para a AWS e para armazenamento no S3. O Wal-e ainda pode trabalhar com o Google Cloud, com o Azure e com o sistema de disco, você pode especificar algum tipo de unidade remota. O Wal-g funciona apenas com a AWS, apenas com S3. Bem, ou qualquer outra interface semelhante com o S3. Nós os usamos, coisas boas. Desmontarei ainda mais cada ferramenta em detalhes.



E no próximo pacote de ferramentas, essas são ferramentas que dependem do pg_basebackup ou o usam diretamente, ou de alguma forma implementam sua funcionalidade. Todos eles são escritos por desenvolvedores que se comprometem com o PostgreSQL principal e têm seu próprio comercial de fork, que promove em seu círculo de influência.
A ferramenta de barman mais popular, que usamos amplamente no país. Este é essencialmente um wrapper Python em torno de pg_basebackup. Também pode funcionar em protocolos ssh. Uma ferramenta pgbackrest muito interessante e muito promissora. O PostgreSQL está envolvido no desenvolvimento e se compromete ativamente com ele. Foi originalmente escrito em Python. Agora a versão usada - está escrita em C para acelerar e a possibilidade de remoção paralela de backups.
Pg_probackup é um utilitário de nossos colegas russos no PostgreSQL Professional que permite fazer backups incrementais, que são bem pequenos em tamanho.
E o utilitário mais recente é a ferramenta de backup e recuperação (BART) do EnterpriseDB. Ela não é muito popular entre nós. É principalmente para o CentOS e Red Hat. Para o Ubuntu, com ela, na minha opinião, difícil. E devido à baixa popularidade do BART conosco, ele (BART) quase não é encontrado em nenhum lugar das instalações.



Eu tentaria dividir essas ferramentas em algumas coisas importantes.


  • Primeiro, é importante para nós como armazená-lo, em quais unidades e em quais serviços. E há uma lista de características pelas quais passaremos.


  • A seguinte separação de dados, aqui subdivido o que podemos, ao remover um backup ou restaurar um backup, para cortar um pedaço de todo o servidor de banco de dados (servidor) e trabalhar com ele como um banco de dados integral e integral.


  • Quanto eles suportam versões diferentes do banco de dados.


  • Quais modos de operação eles têm em termos de paralelismo, em termos de algum tipo de automação e similares.


  • E a capacidade de manutenção é o quanto podemos separá-los em um serviço separado, que por si só passará por bancos de dados e removerá os backups de acordo com alguma programação.


  • Validação - Eu queria que o backup fosse verificado em termos de garantir que possamos recuperar dele e teremos uma base normal e ininterrupta.


    E agora, vamos examinar esses seis grandes pontos com mais detalhes. E vou marcar lá qual o instrumento que nos dará.




Por armazenamento, eles podem armazenar tudo no sistema de arquivos, ou seja, podemos remontar nosso disco no sistema operacional e copiar os backups lá. Todas as ferramentas permitem que você faça isso. Uma unidade de rede montada é basicamente a mesma, porque é obtida em nosso sistema de arquivos local.
Na AWS (S3), três ferramentas podem funcionar para nós - wal-g, wal-e, pgbackrest. Porque entre esses utilitários: barman e assim por diante, é o único que pode trabalhar com a AWS (S3).
Com o Azure, apenas wal-e. O Google Cloud é apenas wal-e.



  • Uma cópia lógica dos dados é fornecida apenas por pg_dump, pg_dumpall. A diferença entre eles é que pg_dumpall processa toda a instância do banco de dados (servidor); em pg_dump, você pode especificar um banco de dados específico na instância e trabalhar com ele.
  • Cópias binárias são o resto.
  • Um fator importante durante o armazenamento é que, se estamos limitados de alguma forma pelos recursos do disco, geralmente surgem situações quando dividimos o banco de dados em diferentes espaços de tabela. Isso também vale para servidores de ferro, porque você não deseja sofrer com RAID. Isso é verdade para as nuvens, porque, porque há uma certa limitação, especialmente quando você pega um carro com discos NVME e quantos estão conectados, muitos estão conectados. As instâncias da AWS se expandem, mas com as unidades EBS. E ao restaurar dados, será importante para nós podermos redistribuir esses espaços de tabela, atribuí-los ao longo de novos caminhos e a novos discos. E agora essa boa propriedade está presente na wal-e. No wal-g, eles ainda não sabem como trabalhar com isso. Pg_probackup pode trabalhar com ele. Barman, basebackup, pgbackrest. Isso geralmente é importante, especialmente quando você tem um banco de dados de 8 a 10 TB. Entre nossos clientes de produção, quase todos esses bancos de dados são recolhidos em espaços de tabela.


Agora, sobre qual tamanho podemos ter backup. Tudo isso ocorrerá no contexto de backups binários. É claro que o backup binário é o quanto o banco de dados pesa conosco, tanto que copiamos. Pesa 8 TB, copiamos 8 TB. 1 MB pesa 1 MB, copiado. Como economizar espaço quando queremos uma longa cadeia de backups? Para fazer isso, veio com algumas ferramentas. Ou seja, o banco de dados armazena dados em seus arquivos. Se tivermos um banco de dados de arquivamento longo, geralmente alteramos lá uma pequena porcentagem desses arquivos. E para isso, eles criaram um backup diferencial.


Backup diferencial, o que é? Examinamos quais arquivos foram alterados e copiamos apenas para o armazenamento, onde armazenar o backup. E vincularemos todos os outros arquivos com um hardlink a esse banco de dados. Acontece que, assim, economizamos espaço. E, ao mesmo tempo, podemos excluir com segurança os backups antigos do banco de dados sem estragar os mais recentes.


Isso é bom, mas decidimos ir em frente e criamos um backup incremental. Os backups incrementais são de dois tipos.


O primeiro está no nível do arquivo. Ele difere do backup diferencial apenas porque o backup diferencial se concentra em um backup completo do seu banco de dados e, em relação a um backup completo, copia arquivos e cópias diff. O backup incremental pode se concentrar em backups diferenciais, copia apenas os arquivos alterados que foram alterados em comparação ao backup diferencial. Para incremental, você precisará de toda a cadeia de backups. Ou seja, o backup principal -> 1º backup incremental (sempre será diferencial) -> todos os backups incrementais. O backup diferencial sempre se concentra em um banco de dados de backup completo. Incremental pode se concentrar em outros tipos de backup.
Pg_probackup e BART foram o caminho para criar backups incrementais por bloco. Porque podemos mudar não o arquivo inteiro, mas o bloco de dados. E esses utilitários percorrem os arquivos wal e selecionam exatamente os blocos que foram alterados. Esses blocos de backup são copiados para o backup. Para recuperar com esse backup incremental, você também precisará de uma cópia completa do banco de dados e ainda precisará salvar essas partes incrementais digitadas no wal. Isso impõe algumas limitações do utilitário, porque elas devem ser executadas nos arquivos wal. O PostgreSQL Professional também possui uma camada sobre a estrutura de arquivos do banco de dados. Portanto, eles estão procurando rapidamente esses blocos. Esses backups incrementais são muito pequenos. Se você tiver uma pequena alteração de% do banco de dados e devido ao fato de muitas informações técnicas serem gravadas no arquivo wal, esses utilitários fazem backup de dezenas de kilobytes de dados por 1 wal.



Mais compartilhamento de dados. Isso implica que, se precisarmos fazer backup, nem tudo. Ou restaure nem tudo. Isso só é possível com backups lógicos, e isso nos permite fazer apenas pg_dump. Utilitários fornecem funcionalidade bastante ampla. Pg_dump pode permitir que você despeje a estrutura do banco de dados, se necessário. Você pode despejar especificamente uma tabela ou pode excluir uma tabela do despejo ou despejar a lista de tabelas, excluir a lista. A funcionalidade é bastante ampla nesse sentido. O ponto negativo é que, ao recuperar-se de um dump desse tipo, se você tiver um banco de dados grande, precisará gastar muito tempo para recuperá-lo, porque tudo isso precisa ser reproduzido em uma instância pura do PostgreSQL.
Esses utilitários são muito convenientes para usar o caso quando superestimamos nossos pontos fortes e não criamos muitos bancos de dados pequenos. Podemos mesclá-los em uma instância. Podemos vê-lo dessa maneira, se agora avaliarmos novamente nossa força, nosso banco de dados está inchado ou estamos mudando a arquitetura de um monólito para um serviço e vendo os dados. Pg_dump neste caso é a única coisa que permite fazer isso sem problemas.


Você também pode restaurar um banco de dados e o pgbackrest está listado aqui. Ele possui um chip, e podemos indicar que precisamos de apenas um banco de dados do backup binário. O que ele esta fazendo? Restaura o banco de dados padrão do backup, este é o template, o postgres e o banco de dados que especificamos. Em todos os outros bancos de dados, ele redefine arquivos e os torna com tamanho zero. Ou seja, o PostgreSQL possui uma estrutura transparente para armazenar bancos de dados em arquivos; nesse nível, você pode, por assim dizer, reduzir o banco de dados restaurado. Suponha que precisamos encontrar quais dados urgentes de um binário, não queremos aumentar uma base de 10 TB, temos duas bases lá e aumentamos uma, o que permite um total de 5 TB. Nesse caso, é claro, a consistência é violada, mas para algumas soluções rápidas, quando você precisa levantar urgentemente dados do furo do nariz de um banco de dados grande, dos quais existem vários, esses são recursos muito bons. Mas como um banco de dados de backup completo não deve ser considerado durante a recuperação. Ou seja, é para trabalhos de emergência.



Como é o trabalho com muitas versões do banco de dados? Aqui também tudo é bastante interessante. Pg_dump é muito bom, pois não estamos vinculados a qual versão do banco de dados restaurar. Há um modo de texto sem formatação, e é apenas SQL puro, que descreve toda a estrutura do banco de dados, todos os dados. Em princípio, você pode se recuperar de onde quiser, no MySQL, no MSSQL, no Oracle, com algumas edições neste dump. Entre as principais versões do PostgreSQL, esses dumps também são bastante fáceis de usar.
Multi-versioning, o que quero dizer com isso? É assim que o utilitário pode processar versões diferentes de bancos de dados e trabalhar simultaneamente com o PostgreSQL 9.6, 10, 11. Tudo, exceto os integrados de pg_dump e pg_basebackup, porque eles estão vinculados à versão específica que eles acompanham. O restante se concentra nesses utilitários. Eles podem ser indicados onde estão localizados pg_basebackup, pg_dump de diferentes versões. Eles respectivamente com a versão do PostgreSQL escolhem o utilitário mais recente para remover o backup.
Todos os utilitários, exceto pg_dump, são adequados para criar réplicas e servidores em espera, porque esses são backups lógicos. Usando qualquer um desses utilitários, você pode restaurar os servidores e conectar-se ao assistente para funcionar como uma réplica desse servidor.



Como os backups podem ser removidos em geral, quais modos existem para remover backups. Você pode simplesmente copiar arquivos usando as ferramentas padrão do sistema operacional: via protocolo ssh (rsync, scp) e, possivelmente, outros utilitários. Por que existe essa oportunidade, porque eles permitem que você paralelize a cópia. O Pgbackrest só funciona dessa maneira, barman pode funcionar dessa maneira e pode funcionar usando o protocolo PostgreSQL.
Protocolo PostgreSQL - quando o utilitário de backup se conecta ao PostgreSQL e extrai todos os arquivos e logs de arquivamento que surgem durante o processo de backup usando o protocolo de replicação. Todo mundo e barman podem fazer isso.
Basicamente, tudo pode fazer backup de uma réplica, depende da versão do PostgreSQL. Com o PostgreSQL 10 e 11, podemos remover backups de uma réplica. Mas eu não recomendo isso, em geral, nenhuma empresa recomenda. Como há situações em que eles perderam o monitoramento, eles fizeram um backup da réplica por um mês, que caiu do servidor mestre e não é relevante. Ou seja, os backups sempre devem ser removidos do servidor mestre. Somente nesse caso, você terá certeza de que possui um banco de dados de backup realmente atualizado.
Backups multithreading - todos podem fazer isso, porque tudo é por diferentes razões, alguém através do protocolo ssh, alguém implementado no nível de cópia do banco de dados. Além de pg_basebackup e BART, porque a operação BART está apenas em pg_basebackup quando o backup é removido e, infelizmente, é de thread único e não será multithread.



Um exemplo de multithreading. Eu estava restaurando um banco de dados de 8 TB. Quando você se concentra na escolha de um sistema para remover backups, saiba que o wal-e está escrito em Python, o wal-g está escrito em Golang. Eu tive que restaurar a base de 8 TB. Wal-e encontrou a limitação do Python e me puxou com a AWS a uma velocidade de 600 Mbps. Quando mudei para o wal-g, ele tinha uma situação em que não podia trabalhar com backups do wal-e, mas podia puxar arquivos wal. Portanto, essa imagem do meio aqui é a restauração do banco de dados. Em seguida, rolou o wal, que estava lá no S3 e foi restaurado para um determinado ponto no tempo. O Wal-e encontrou limitação e simultaneidade em Python em Python, é tão condicional. Um wal-g correu para a interface S3, ou seja, quão rápido o S3 podia dar a cada momento, tão rapidamente que demorava. Em média, era de 2 Gb / s, o que é bom o suficiente. Ou seja, com o wal-e, uma hora de alterações no banco de dados foi recebida em 45 minutos de backup contínuo. Com o wal-g, eles rolaram uma hora em algum lugar do banco de dados por cerca de 5 minutos.



Modos de operação, o que é interessante aqui no sistema de backup.


  • Recuperação a tempo para um ponto específico. Se arquivamos logs e os copiamos, podemos restaurá-los. Ele permite que você faça um sistema de backup, como um fator padrão. O principal é que armazenamos arquivos wal em algum lugar. Os lixões, é claro, não sabem como, porque são um pouco sobre outra coisa.
  • Ajustar a carga na rede é uma coisa muito importante, porque, como eu disse, é desejável remover o dump do servidor mestre e garantir que você realmente obtenha o backup real. Bem, às vezes acontece que os servidores estão tão carregados que é muito difícil entrar lá. Alguns clientes mantêm uma interface de rede separada. Às vezes, é feito um tempo de carregamento mínimo. Também é bom quando podemos especificar a carga na rede ao criar backup. Isso permite que você faça pg_basebackup, barman e BART, wal-e, wal-g.
  • Compressão em tempo real. Esta é uma questão de quanto transmitiremos pela rede. Se pudermos compactar o arquivo antes de enviá-lo para o repositório, isso será bom em tempo real. E quase todo mundo pode fazer isso aqui. O principal é indicar o nível de compressão lá.


Facilidade de manutenção, o que é interessante aqui para sistemas de backup?


  • CLI — , , , , . , CLI, , , . , , .
  • barman, pgbackrest BART, . , 20-30 , , , , backup- . , , .
  • – , , backup-, , backup-. , - . . .
  • – backup-, , - . , , . , , , , wal , , . wal-e, wal-g, , backup - . 7 backup .


backup. , backup, backup , , . , . , . . stage . , , backup . CLI , backup .


, , . , backup . , . , . , . . checksum PostgreSQL. , checksum PostgreSQL. checksum, .


pgbackrest pg_probackup backup , checksum. checksum.


, backup, checksum , , checksum . .



:



. , . , .



: , backup , , , . , , backup. , , - , , , , , , . - ?


: , , . . . - , , backup , , , . , . , , , , , , / . , , . , . , . , .


: , , ? .


: . 4 . . . backup. . , .


: ?


: . . wal-e, wal-g, pgbackrest. borman, pg_dump, basebackup. , , . .


: , - PostgreSQL, , , postgis - -?


: , backup , . checksum , PostgreSQL checksum, , . postgis, - . Pg_dump , , , SQL . SQL . . , , . dump, .


: , . , - ?


: . dump , . , – , , - , , . , . , - , .


: , , , bloat ?


: .


: — , - . , Symantec, Veritas Backup Exec . PostgreSQL?


: , , . PostgreSQL , pg_start_backup. , . .


: , - Symantec, Veritas Backup Exec .


: .


: , , . checksum - , , - ?


: — . stage , . stage . . . , -, . . .


: , WAL , S3. wal-e, wal-g - awscli . ?


( ): wal-g. wal-g. 40 wal-g . . , . , prefetch, wal , . , — , wal. wal , page cache , , wal, , . , .


: . , PostgreSQL — -> /dev/null, , . , . smoke . amcheck , . , , , .


: 10 . . . . wal — . ?


: . . . , .


: , pg_dump, . ?


: - . , .


: , , - ?


: pg_dump , .


: pg_dump, , , , , .


: , -, .


: , .


: , - .


: . . . . , , . . Pg_dump , - , exit_code . , , . , .


PS №1 pg_dump, pg_basebackup.


barmanwal-ewal-gpg_probackuppgbackrestBART
ssh (rsync, scp)++
++++++
S3+++
Azure++
Google Cloud++
+++++
++
++
barmanwal-ewal-gpg_probackuppgbackrestBART
++
+
-++++++
+++++
Recuperação Point-in-Time++++++
Ajuste de carga de rede+++
Compactação dinâmica+++++
CLI++++++
Servidor dedicado+++
barmanwal-ewal-gpg_probackuppgbackrestBart
Armazenamento de backup estruturado++++++
Políticas de retenção+croncron+++
CLI para monitoramento++++++
Validade da conclusão do backup++++++
Soma de verificação postgresql++

PS No. 2 Erros, correções nos termos do artigo, adições à tabela dinâmica podem ser feitas através da solicitação Pull


PS # 3 Wal-g recebe voluntários para ajudar com a documentação.


PS No. 4 Para instalar o wal-g usando o rpm, você pode usar o meu repositório: Github , Fedora COPR .


PS No. 5 Como fazer backup completo e backup incremental na criação e armazenamento no S3 e salvar apenas o backup completo em fita? Se você tiver idéias, conte-me nos comentários ou no PM.



Pesquisa: Quais ferramentas de backup você usa?


Canal de telegrama PS nº 6 PostgreSQL: https://t.me/pgsql

Source: https://habr.com/ru/post/pt485622/


All Articles