Várias palestras programadas serão baseadas no primeiro Y. Subbotnik em bancos de dados realizados
na primavera . Primeiro, o desenvolvedor Andrei Borodin falou no Y. Subbotnik. Ele falou sobre o WAL-G, uma ferramenta simples e eficaz para fazer backup do PostgreSQL na nuvem, bem como algoritmos e tecnologias que permitem ao WAL-G criar backups mais rapidamente. A principal característica do WAL-G são os backups delta. Na palestra, você aprenderá sobre a implementação deles e como o suporte a essa tecnologia está se desenvolvendo no PostgreSQL.
oi! Sou desenvolvedor Yandex de Yekaterinburg. Para a tecnologia de backup rápido. Fazemos backup há algum tempo; houve relatos de
Vladimir Borodin e
Evgeny Dyukov sobre como pesquisamos e o que desenvolvemos para armazenar dados com segurança, confiabilidade, conveniência e eficiência. Esta série é dedicada aos mais recentes desenvolvimentos nesta área.
Vamos falar sobre backups no PostgreSQL em princípio. O utilitário padrão para transferência de dados -
pg_dump - é definido como um utilitário do console que cria um arquivo com uma representação lógica dos seus dados.
O fato de ser uma cópia lógica é bastante conveniente. Você sempre pode transferir dados entre versões diferentes, pode cortar seu banco de dados em pedaços, e esta é uma ferramenta padrão que, por exemplo, vem em uma caixa com o utilitário de administração PgAdmin.
Primeiro de tudo, sobre o pg_dump, você precisa saber que esta é uma ferramenta de desenvolvedor.
Esta não é uma ferramenta de manutenção de banco de dados. O pg_dump não foi projetado para funcionar com um banco de dados altamente carregado.
Suponha que tudo seja sério e você queira usar a tecnologia "Recuperação pontual", que usa a API do PostgreSQL para trabalhar com backups online. Você chama a função pg_start_backup e faz uma cópia do arquivo do banco de dados. De fato, pg_start_backup força o banco de dados a executar o CHECKPOINT; e habilite gravações de página inteira no log de gravação antecipada. A cópia do banco de dados que você cria quando chama a API não é uma cópia consistente dos dados. Você também precisa de um log write-ahead para poder restaurar seu banco de dados durante a chamada pg_stop_backup, ou seja, no final do backup.
Após o término da remoção do backup e na presença de um registro inicial, você pode recuperar o ponto desejado na vida útil do seu banco de dados.
O utilitário pg_basebackup é fornecido na caixa, que implementa toda essa tecnologia de forma canônica e permite fazer backup com a funcionalidade mínima necessária.
Se você ainda é mais sério do que antes, usa algum tipo de software de gerenciamento de backup e, geralmente, é o Barman.
Ele tem várias vantagens. A principal vantagem é um utilitário muito comum, possui uma comunidade enorme, um grande número de perguntas sobre o Stack Overflow.
Você só precisa pegar um servidor de backup e fazer backup de todo o seu PostgreSQL lá. Isso é muito conveniente - desde que um servidor de backup seja suficiente para você.
Assim que você tiver muitos servidores de backup, precisará monitorar se algum deles está cheio. Em caso de falha de algum servidor de backup, você precisa entender quais bancos de dados estão em perigo. Você precisa entender em princípio onde copiar um novo cluster de banco de dados ao criá-lo.
Existe um utilitário de remoção de backup muito mais simples chamado WAL-E.
O WAL-E executa quatro comandos principais. O comando WAL-PUSH envia um arquivo WAL para a nuvem e o WAL-FETCH pega um arquivo WAL se restore_command precisar ser restaurado.
Também há BACKUP-PUSH (implementa a remoção da API de backup) e BACKUP-FETCH (coleta todos os dados da nuvem). Os dados são armazenados na nuvem; portanto, você não precisa monitorar nada, isso já é um problema de serviço em nuvem, como garantir a disponibilidade dos seus dados quando você precisar. Esta é provavelmente a principal vantagem do WAL-E.
Existem muitas funcionalidades. Há uma lista de backups, há uma política de retenção, ou seja, queremos armazenar backups nos últimos sete dias, por exemplo, ou nos últimos cinco backups, algo assim. E o WAL-E pode fazer backup para uma enorme variedade de serviços em nuvem: S3, Azure, Google, pode chamar o sistema de arquivos local de nuvem.
Tem várias propriedades. Primeiro, ele é escrito em Python e usa ativamente o pipeline do Unix, em parte por causa disso, possui dependências e não é muito produtivo. Isso é normal porque o WAL-E se concentra na facilidade de uso e na configuração, para que você não cometa erros ao fazer um plano de backup. E essa é uma ideia muito boa.
Existem muitos recursos escritos no WAL-E, e onde os autores o desenvolveram ainda não foi muito claro para os autores. Surgiu a ideia de que eu precisava de uma nova ferramenta.
Sua principal característica é que ele é reescrito no Go, não possui quase dependências externas, se você não usar criptografia externa, e é muito mais produtivo.
O WAL-G foi originalmente criado por dois autores do Citus Data, e a principal vantagem é mostrada neste histograma - a velocidade de envio dos "eixos". Vemos que o WAL-E é rápido, pode ser qualquer coisa, pode ser uma grande coluna perto de zero.
O WAL-G possui uma largura de banda bastante estável. Em testes no Citus Data, ele mostrou que envia de forma estável cerca de 800 Mb / s de "eixos".
Além disso, no WAL-G, por exemplo, escrevi um recurso que implementa backup de uma réplica. Você não precisa carregar seu mestre de banco de dados com uma carga de leitura; é possível remover o backup da réplica.
Mas há um pequeno problema. No momento em que você começa a fazer o backup, nomeie-o de alguma forma. O nome inclui uma linha do tempo, que será alterada se uma réplica for promovida. Se ocorrer um failover na cadeia de réplicas antes da réplica com a qual você está fazendo backup, você notará algumas das réplicas, a linha do tempo será alterada. O WAL-G entende que essa situação não é consistente, pois, tendo um nome na linha do tempo antiga, o nome promete que você poderá continuar o desenvolvimento do histórico do banco de dados em qualquer direção existente. Mas isso não é verdade. Você já foi a uma das direções; não pode pular para outra linha do tempo com o carro de volta. Portanto, o WAL-G entende essa situação e não faz upload de um arquivo JSON fiscal na nuvem. Você cria uma cópia física. Mas é necessária intervenção do administrador para que esta cópia possa ser usada.
Implementamos cópias delta no WAL-G, também trabalhei nesse desenvolvimento. Isso permite que você obtenha menos dados no próximo backup de base, não faça uma cópia dessas páginas de dados que não foram alteradas no backup anterior.
Ao configurar o WAL-G, você especifica o número de etapas que estão mais distantes do backup base, do backup delta e da política de cópia delta. Você faz uma cópia do último delta existente ou faz um delta do backup completo original. Isso é necessário no caso em que o mesmo componente do banco de dados sempre muda no seu banco de dados, os mesmos dados estão constantemente mudando.
Por que, em princípio, precisamos de cópias delta do banco de dados? Em teoria, você tem um WAL e pode rolar para qualquer lugar.
Em um servidor ocupado, a reprodução do WAL de cinco segundos físicos do passado pode levar quatro segundos físicos do presente. Se você for solicitado a rolar o WAL em quatro dias, isso significa que é possível que a pessoa que solicita isso espere mais três dias. Nem sempre é uma situação aceitável.
Você precisa de backups básicos para todos os dias, mas, no entanto, não é possível armazenar 7 ou 14 cópias completas do seu banco de dados, mesmo que o WAL-G os arquive, ele ainda será muito grande. E, neste caso, cópias delta ajudam.
Ao desenvolver cópias delta, vários formatos possíveis de arquivos de dados foram discutidos. Antes de tudo, o formato foi proposto; quando não perturbamos a página, simplesmente a anulamos. Mas chegamos à conclusão de que essa não é uma maneira muito eficaz, os zeros são efetivamente compactados, mas recusamos esse método de armazenamento, porque é difícil depurá-lo em caso de situações de emergência.
A próxima tecnologia considerada é primeiro armazenar o número do bloco e depois o bloco alterado. Mas aqui nos deparamos com a peculiaridade do armazenamento em arquivos TAR, que precisamos primeiro indicar o tamanho dos arquivos TAR nos quais armazenamos nossa cópia delta e depois começar a gravá-la. Eu queria fazer a implementação da tecnologia com um mínimo de RAM consumida, então tivemos que usar o terceiro formato no qual lemos completamente cada arquivo de dados, procuramos as páginas de dados alteradas, primeiro armazenamos o número dos blocos alterados no arquivo TAR e somente então os próprios blocos alterados.
Esse recurso ainda não foi implementado. Estou olhando para ela ou procurando alguém que queira fazer uma solicitação pull no WAL-G. Ao se recuperar de uma cópia delta, o banco de dados sobrevive a cada uma das reencarnações do banco de dados em cada etapa do backup delta. Às vezes, no meio da vida, alguns arquivos são excluídos. Ao mesmo tempo, não precisaríamos nos preocupar com a condição deles se eles fossem excluídos de qualquer maneira e depois recriados a partir da cópia delta. Esse não parece ser um recurso muito complicado; portanto, se você estiver interessado em escrever algo sobre o Go, consulte esse recurso.
Agende sobre o uso de rede, CPU e disco. No WAL-E, como podemos ver, o backup aqui ainda não terminou, começou às uma da manhã em Moscou e não terminou no último relatório que vemos. O cronograma do WAL-G terminou, funciona mais rápido e é muito mais uniforme em termos de consumo de recursos.
O mais interessante é o gráfico do consumo de recursos durante uma cópia delta. Vemos que todos os recursos se tornaram quase zero. A carga na CPU é quase a carga padrão no banco de dados; à noite, algumas consultas são executadas. Vemos um grande ponto de leitura. Eu também lido com isso, também gostaria de receber um pedido ou farei eu mesmo no verão. O ponto principal é que ainda precisamos ler nossos dados para descobrir o que mudou neles. Esta leitura poderia ter sido evitada.
Há uma exclusão no WAL-G quando indicamos o número de backups ou a data a partir da qual precisamos armazenar todos os WALs e todos os backups de base. E o WAL-G já está lidando com a questão de quais WALs e backups básicos são necessários. Até o momento, não temos recursos que excluam tudo. No WAL-E, é também uma ocasião para uma solicitação de recebimento. Um comando interessante DELETE TUDO ainda não foi implementado.
Há uma lista de backups.
Definimos a variável de ambiente necessária para o WAL-G funcionar e chamamos o utilitário do console WAL-G. Os backups que precisamos visualizar são exibidos.
O WAL-G implementa várias tecnologias para backups paralelos e geralmente várias operações. Por exemplo, essa tecnologia é usada para enviar "eixos" para o arquivo. Assim que o PostgreSQL chama archive_command para enviar um arquivo, o WAL-G procura ver se há mais arquivos por perto prontos.
Em geral, esse não é um recurso muito documentado, é muito estável nas versões mais recentes do PostgreSQL; muitas tecnologias o utilizam. Examinamos se há arquivos WAL prontos no status de arquivamento e também os enviamos junto com o que pediu para enviar o banco de dados para o arquivamento. E quando o PostgreSQL pede que eles enviem, nós já os enviamos, estamos prontos. Isso acelera significativamente o envio de WALs em bases carregadas e permite que você não seja um thread único. Normalmente, o PostgreSQL prepara um arquivo, depois espera que ele vá, prepara o próximo. Conseguimos evitar esse trabalho consistente.
Durante o WAL-FETCH, quando o cluster é restaurado, também tentamos fazer o download dos N arquivos a seguir necessários e equilibrar as pausas entre o início da pré-definição de novos arquivos WAL, para que possamos utilizar todos os recursos que temos o máximo possível: seja executado na rede ou executar em um disco em casos raros.
Tudo isso é definido por variáveis de ambiente.
Também há simultaneidade de fazer uma cópia. Embora esse recurso não esteja presente em várias versões - A.B foi lançada na versão 0.1.10 em junho de 2018 -, já que o paralelismo da leitura do disco permite garantir a execução em uma rede ou em um disco. Isso não é muito bom com um banco de dados carregado. O WAL-E tinha um recurso que permitia a otimização. Até agora, não temos isso. É necessário limitar a velocidade da remoção do backup, para que a base possa viver sua própria vida e servir a carga.
Nossa principal característica não é realmente sobre tecnologia.
Dois anos atrás, Zhenya Dyukov implementou a
tecnologia delta-backup para Barman, ainda não foi realizada, a comunidade ainda está discutindo isso.
Há quase um ano, Zhenya corrigiu o bug do WAL-E e o enviamos por seis meses (
link para o GitHub - aprox. Ed.). Muitas vezes, em soluções de código aberto, há um problema com o fato de que elas não são muito bem mantidas.
Com o WAL-G, tudo é bem simples: usamos e eu mantenho. Se você ou você precisar de algo, basta relatar que tem um problema. Vamos tentar resolvê-lo.
A solicitação padrão da comunidade é simples - "vamos fazer isso mais".
Mais criptografia, mais plataformas. Talvez não apenas o PostgreSQL, mas o MySQL ainda faça backup ou algo mais? Eu vejo algumas outras coisas.
Antes de tudo, agora, ao enviar o "eixo", pudemos entender quais blocos de banco de dados foram alterados, digitalize esses arquivos WAL e salve informações sobre o que foi alterado.
E quando o cron chega com outro backup delta, não conseguimos digitalizar todo o banco de dados, arquivar esse dente da leitura do disco e apenas saber quais páginas precisamos arrastar para a nuvem.
Tentamos usar a tecnologia de rastreamento de página. Ele implementa o rastreamento de alterações de página no nível do kernel do banco de dados. O backup é removido muito rapidamente. O principal problema com o PTRACK é que ele é muito invasivo. Ele contém muitas alterações no núcleo do PostgreSQL em locais muito sensíveis, portanto é improvável que seja adotado em breve.
Além disso, seus deltas são ligeiramente diferentes dos que temos agora. Ao remover o delta baseado em LSN, removemos todas as alterações no arquivo delta ocorridas desde o início anterior até a hora atual.
No caso do PTRACK, obtemos alterações no arquivo delta, a partir do delta anterior recebido. Não temos o tempo delta exato antes do início do backup, antes do início das alterações. Este não é o principal problema do PTRACK, em geral, ele funciona bem, mas até agora é difícil de aceitar.
O PTRACK não permite a remoção delta no modo LATEST_FULL, porque armazena um mapa de blocos alterados da remoção anterior deste mapa. A Oracle tem uma tecnologia interessante, existem 8 cartões anteriores que eles salvam por precaução. Talvez possamos fazer algo semelhante, mas até agora não estamos trabalhando nessa direção.
Em setembro passado, tentei oferecer à comunidade uma tecnologia baseada no fato de que apenas adicionamos os ganchos necessários ao kernel e implementamos o rastreamento de páginas alteradas na extensão para que o patch de rastreamento de páginas não seja muito invasivo. Depois de discutir essa tecnologia, chegamos à conclusão de que precisamos de vários protótipos e adicionaremos ganchos quando houver protótipos. Talvez veremos como eles funcionam. Atualmente, estou trabalhando em protótipos dessas extensões que poderiam usar ganchos do kernel para rastrear alterações no banco de dados.
Há uma expressão na comunidade de que todo postgresista deve ter sua própria ferramenta de backup. Isso é ruim. Todo mundo faz suas próprias coisas, o que faz uma tarefa crítica. Deve haver uma coisa em que tudo estará na caixa, tudo será perfeito em um mundo ideal.
O que eu gostaria de ver em uma caixa no basebackup? Gostaríamos de ver, provavelmente, arquivando na nuvem. E cópias delta.
Eu também gostaria de compactação, simultaneidade, criptografia, limitação, listagem de backups, verificação, validação de backups ... Muitas coisas. Entendemos que se tudo isso agora for oferecido à comunidade, resultará em várias dezenas de patches, que são bastante difíceis de discutir e implementar por meio do commitfest. Portanto, agora ainda estamos usando uma ferramenta separada, mas há um desejo de dedicar tempo e tecnologia à comunidade para melhorar o PostgreSQL.