Sugiro que você leia a transcrição do relatório do início de 2019 de Andrey Borodin "Backups com WAL-G. O que há em 2019?"
Olá a todos! Meu nome é Andrei Borodin. Sou desenvolvedor da Yandex. Estou interessado no PostgreSQL desde 2016, depois que conversei com os desenvolvedores e eles disseram que tudo é simples - você pega o código-fonte e constrói, e tudo vai dar certo. E desde então não consigo parar – escrevo todo tipo de coisas diferentes.
Uma das coisas em que estou trabalhando é um sistema de backup. . Em geral, na Yandex trabalhamos há muito tempo em sistemas de backup em PostgreSQL. E você pode encontrar na Internet uma série de seis relatórios sobre como fazemos sistemas de backup. E a cada ano eles evoluem um pouco, desenvolvem-se um pouco e ficam mais confiáveis.
Mas hoje o relatório não trata apenas do que fizemos, mas também do quão simples é e do que é. Quantos de vocês já assistiram minhas reportagens sobre o WAL-G? Que bom que muita gente não assistiu, porque vou começar pelo mais simples.
Se de repente você tiver um cluster PostgreSQL, e eu acho que todo mundo tem alguns deles, e de repente ainda não há sistema de backup, então você precisa obter qualquer armazenamento S3 ou armazenamento compatível com Google Cloud.
Por exemplo, você pode vir ao nosso estande e obter um código promocional do Yandex Object Storage, que é compatível com S3.
Em seguida, crie um balde. É apenas um recipiente para informações.
Crie um usuário de serviço.
Crie uma chave de acesso para o usuário do serviço: aws-s3-key.
Baixe a versão estável mais recente do WAL-G.
Como nossos pré-lançamentos são diferentes dos lançamentos? Muitas vezes me pedem para liberar mais cedo. E se não houver bug na versão por tempo suficiente, por exemplo, um mês, então eu libero. Aqui está este lançamento de novembro. E isso significa que todo mês encontramos algum tipo de bug, geralmente em funcionalidades não críticas, mas ainda não lançamos um lançamento. A versão anterior é apenas novembro. Não há bugs conhecidos por nós nele, ou seja, bugs foram adicionados à medida que o projeto avançava.
Depois de baixar o WAL-G, você pode executar um comando simples de “lista de backup”, passando as variáveis de ambiente. E ele se conectará ao Object Storage e informará quais backups você possui. No início, é claro, você não deveria ter backups. O objetivo deste slide é mostrar que tudo é bastante simples. Este é um comando de console que aceita variáveis de ambiente e executa subcomandos.
Depois disso, você pode fazer seu primeiro backup. Diga “backup-push” no WAL-G e especifique no WAL-G a localização do pgdata do seu cluster. E muito provavelmente, o PostgreSQL lhe dirá, se você ainda não possui um sistema de backup, que precisa ativar o "modo de arquivamento".
Isso significa que você precisa ir nas configurações e ativar “archive_mode = on” e adicionar “archive_command”, que também é um subcomando no WAL-G. Mas, por alguma razão, as pessoas costumam usar scripts de barra neste tópico e envolvê-los no WAL-G. Por favor, não faça isso. Use a funcionalidade encontrada no WAL-G. Se estiver faltando alguma coisa, escreva para . WAL-G assume que é o único programa executado em archive_command.
Usamos WAL-G principalmente para criar um cluster de alta disponibilidade no gerenciamento de banco de dados Yandex.
E geralmente é usado em uma topologia de um Mestre e várias replicações. Ao mesmo tempo, faz uma cópia de backup no Yandex Object Storage.
Os cenários mais comuns são a criação de cópias de um cluster usando a recuperação pontual. Mas neste caso, o desempenho do sistema de backup não é tão importante para nós. Precisamos apenas fazer upload de um novo cluster do backup.
Normalmente, precisamos de desempenho do sistema de backup ao adicionar um novo nó. Por que isso é importante? Normalmente, as pessoas adicionam um novo nó a um cluster porque o cluster existente não consegue lidar com a carga de leitura. Eles precisam adicionar uma nova réplica. Se adicionarmos a carga de pg_basebackup ao Master, o Master poderá entrar em colapso. Portanto, era muito importante para nós podermos carregar rapidamente um novo nó do arquivo, criando uma carga mínima no Master.
E outra situação semelhante. Trata-se da necessidade de reiniciar o Master antigo após a troca do Cluster Master do Data Center com o qual a conectividade foi perdida.
- Como resultado, ao formular os requisitos para o sistema de cópia, percebemos que o pg_basebackup não é adequado para nós quando operamos na nuvem.
- Queríamos ser capazes de compactar nossos dados. Mas quase qualquer sistema de backup que não seja o que vem na caixa fornecerá compactação de dados.
- Queríamos paralelizar tudo porque um usuário na nuvem compra um grande número de núcleos de processador. Mas se não tivermos paralelismo em alguma operação, então um grande número de núcleos torna-se inútil.
- Precisamos de criptografia porque muitas vezes os dados não são nossos e não podem ser armazenados em texto não criptografado. Aliás, nossa contribuição para o WAL-G começou com a criptografia. Concluímos a criptografia em WAL-G, após o que nos perguntaram: “Talvez um de nós desenvolva o projeto?” E desde então trabalho com o WAL-G há mais de um ano.
- Também precisávamos de otimização de recursos, porque com o tempo usando a nuvem, descobrimos que às vezes as pessoas têm uma carga importante de compras à noite e essa carga não pode ser interferida. É por isso que adicionamos a limitação de recursos.
- Bem como listagem e gerenciamento.
- E verificação.
Vimos muitas ferramentas diferentes. Felizmente, temos uma grande seleção no PostgreSQL. E em todos os lugares faltava alguma coisa, alguma pequena função, algum pequeno recurso.
E tendo examinado os sistemas existentes, chegamos à conclusão de que iremos desenvolver o WAL-G. Era um projeto novo então. Foi muito fácil influenciar o desenvolvimento da infraestrutura em nuvem do sistema de backup.
A principal ideologia à qual aderimos é que o WAL-G deveria ser tão simples quanto uma balalaica.
WAL-G possui 4 comandos. Esse:
WAL-PUSH – arquive o eixo.
WAL-FETCH – pegue uma flecha.
BACKUP-PUSH – faça um backup.
BACKUP-FETCH – obtenha um backup do sistema de backup.
Na verdade, o WAL-G também possui gerenciamento desses backups, ou seja, listando e excluindo registros e backups do histórico que não são mais necessários no momento.
Uma das funções importantes para nós é a função de criação de cópias delta.
Cópias delta significam que não criamos um backup completo de todo o cluster, mas apenas das páginas alteradas dos arquivos alterados no cluster. Parece que funcionalmente isso é muito semelhante à capacidade de recuperação usando WAL. Mas podemos acumular um backup delta de thread único WAL em paralelo. Assim, quando temos um backup básico feito no sábado, backups delta diariamente, e na quinta falhamos, precisamos acumular 4 backups delta e 10 horas de WAL. Levará quase o mesmo tempo porque os backups delta são executados em paralelo.
Deltas baseados em LSN - isso significa que ao criar um backup precisaremos combinar cada página e verificar seu LSN com o LSN do backup anterior para entender que ele mudou. Qualquer página que possa conter dados alterados deve estar presente no backup delta.
Como eu disse, muita atenção foi dada ao paralelismo.
Mas a API de arquivo no PostgreSQL é consistente. O PostgreSQL arquiva um arquivo WAL e ao restaurá-lo solicita um arquivo WAL. Mas quando o banco de dados solicita um arquivo WAL usando o comando “WAL-FETCH”, chamamos o comando “WAL-PREFETCH”, que prepara os próximos 8 arquivos para buscar dados do armazenamento de objetos em paralelo.
E quando o banco de dados nos pede para arquivar um arquivo, olhamos archive_status e vemos se há outros arquivos WAL. E também estamos tentando baixar o WAL em paralelo. Isso proporciona um ganho significativo de desempenho e reduz significativamente a distância no número de WALs desarquivados. Muitos desenvolvedores de sistemas de backup acreditam que este é um sistema muito arriscado porque confiamos em nosso conhecimento dos componentes internos do código que não é a API do PostgreSQL. O PostgreSQL não garante para nós a presença da pasta archive_status e não garante a semântica, a presença de sinais de prontidão para arquivos WAL ali. No entanto, estamos estudando o código-fonte, vemos que é assim e estamos tentando explorá-lo. E controlamos a direção em que o PostgreSQL está se desenvolvendo; se de repente esse mecanismo for quebrado, deixaremos de usá-lo.
Em sua forma pura, o WAL delta baseado em LSN requer a leitura de qualquer arquivo de cluster cujo tempo de modo no sistema de arquivos tenha sido alterado desde o backup anterior. Convivemos com isso por muito tempo, quase um ano. E no final chegamos à conclusão de que temos deltas do WAL.
Isso significa que toda vez que arquivamos o WAL no Master, não apenas o compactamos, criptografamos e enviamos para a rede, mas também o lemos ao mesmo tempo. Analisamos e lemos os registros nele contidos. Entendemos quais blocos foram alterados e coletamos arquivos delta.
Um arquivo delta descreve um determinado intervalo de arquivos WAL, descreve informações sobre quais blocos foram alterados neste intervalo de WAL. E então esses arquivos delta também são arquivados.
Aqui nos deparamos com o fato de que paralelizamos tudo muito rapidamente, mas não podemos ler um histórico sequencial em paralelo, pois em um determinado segmento podemos encontrar o final do registro WAL anterior, ao qual ainda não temos nada com o que nos conectar, porque a leitura paralela levou a que analisemos primeiro o futuro, que ainda não tem passado.
Como resultado, tivemos que colocar peças incompreensíveis em arquivos _delta_partial. Como resultado, quando voltarmos ao passado, colaremos os pedaços do registro WAL em um só, depois analisaremos e entenderemos o que mudou nele.
Se houver pelo menos um ponto no histórico de nossa análise de eixo em que não entendemos o que estava acontecendo, então, durante o próximo backup, seremos forçados a ler todo o cluster novamente, assim como fizemos com um LSN normal delta baseado em.
Como resultado, todo o nosso sofrimento levou ao fato de abrirmos o código-fonte da biblioteca de análise WAL-G. Pelo que eu sei, ninguém está usando ainda, mas se alguém quiser, escrever e usar, é de domínio público. (Link atualizado )
Como resultado, todos os fluxos de informação parecem bastante complicados. Nosso Mestre arquiva o eixo e arquiva os arquivos delta. E a réplica que faz a cópia de backup deve receber arquivos delta durante o tempo decorrido entre os backups. Nesse caso, partes do histórico precisarão ser adicionadas em massa e analisadas, porque nem todo o histórico cabe em grandes segmentos. E somente depois disso a réplica poderá arquivar um backup delta completo.
Nos gráficos tudo parece muito mais simples. Este é um download de um de nossos clusters reais. Temos baseado em LSN, feito em um dia. E vemos que o backup delta baseado em LSN funcionava das três da manhã às cinco da manhã. Esta é a carga no número de núcleos do processador. O WAL-delta demorou cerca de 20 minutos até aqui, ou seja, ficou significativamente mais rápido, mas ao mesmo tempo houve uma troca mais intensa pela rede.
Como temos informações sobre quais blocos foram alterados e em que momento do histórico do banco de dados, fomos além e decidimos integrar a funcionalidade - uma extensão do PostgreSQL chamada “pg_prefaulter”
Isso significa que quando a base stand-by executa o comando de restauração, ela diz ao WAL-G para buscar o próximo arquivo WAL. Entendemos aproximadamente quais blocos de dados o processo de recuperação WAL acessará em um futuro próximo e iniciaremos uma operação de leitura nesses blocos. Isso foi feito para aumentar o desempenho dos controladores SSD. Porque o rolo WAL chegará à página que precisa ser alterada. Esta página está no disco e não no cache de páginas. E ele esperará de forma síncrona até que esta página chegue. Mas perto está o WAL-G, que sabe que nas próximas centenas de megabytes de WAL precisaremos de certas páginas e ao mesmo tempo começa a aquecê-las. Inicia vários acessos ao disco para que sejam executados em paralelo. Isso funciona bem em unidades SSD, mas, infelizmente, não é absolutamente aplicável a um disco rígido, porque apenas interferimos com nossos prompts.
Isso é o que está no código agora.
Existem recursos que gostaríamos de adicionar.
Esta imagem mostra que o WAL-delta leva um tempo relativamente curto. E isso é ler as mudanças que ocorreram no banco de dados durante o dia. Poderíamos fazer WAL-delta não só à noite, porque não é mais uma fonte significativa de carga. Podemos ler o WAL-delta a cada minuto porque é barato. Em um minuto podemos verificar todas as alterações que ocorreram no cluster. E isso poderia ser chamado de "WAL-delta instantâneo".
A questão é que, quando restauramos o cluster, reduzimos o número de histórias que precisamos acumular sequencialmente. Ou seja, a quantidade de WAL que o PostgreSQL rola deve ser reduzida, pois leva um tempo significativo.
Mas isso não é tudo. Se soubermos que algum bloco será alterado até o ponto de consistência do backup, não poderemos alterá-lo no passado. Ou seja, agora temos otimização arquivo por arquivo do encaminhamento WAL-delta. Isso significa que se, por exemplo, na terça-feira uma tabela foi completamente excluída ou alguns arquivos foram excluídos totalmente da tabela, então, quando o delta for transferido na segunda-feira e o pg_basebackup de sábado for restaurado, nem mesmo criaremos esses dados.
Queremos estender essa tecnologia ao nível da página. Ou seja, se alguma parte do arquivo for alterada na segunda-feira, mas for sobrescrita na quarta-feira, ao restaurar para um ponto na quinta-feira, não precisaremos gravar as primeiras versões das páginas no disco.
Mas esta ainda é uma ideia que está sendo ativamente discutida dentro de nós, mas ainda não atingiu o código.
Queremos fazer mais um recurso no WAL-G. Queremos torná-lo extensível porque precisamos suportar diferentes bancos de dados e gostaríamos de poder abordar o gerenciamento de backup da mesma maneira. Mas o problema é que as APIs do MySQL são radicalmente diferentes. No MySQL, o PITR não é baseado no log físico do WAL, mas no binlog. E não temos um sistema de arquivamento no MySQL que diga a algum sistema externo que este binlog está concluído e precisa ser arquivado. Precisamos ficar em algum lugar do cron com o banco de dados e verificar se há algo pronto?
E da mesma forma, durante uma restauração do MySQL, não há nenhum comando de restauração que possa informar ao sistema que preciso de tais e tais arquivos. Antes de começar a reconstruir seu cluster, você precisa saber de quais arquivos precisará. Você mesmo precisa adivinhar quais arquivos precisará. Mas esses problemas podem ser contornados de alguma forma. (Esclarecimento: MySQL já é suportado)
No relatório, também queria falar sobre os casos em que o WAL-G não é adequado para você.
Caso não possua uma réplica síncrona, o WAL-G não garante que o último segmento será preservado. E se o arquivamento estiver atrasado em relação aos últimos segmentos da história, isso é um risco. Se não houver réplica síncrona, não recomendaria usar o WAL-G. Ainda assim, está pensado principalmente para uma instalação em nuvem, o que implica uma solução de Alta Disponibilidade com uma réplica síncrona, que é responsável pela segurança dos últimos bytes comprometidos.
Muitas vezes vejo pessoas tentando executar o WAL-G e o WAL-E ao mesmo tempo. Apoiamos a compatibilidade com versões anteriores no sentido de que o WAL-G pode restaurar um arquivo do WAL-E e um backup feito no WAL-E. Mas como ambos os sistemas usam wal-push paralelo, eles começam a roubar arquivos um do outro. Se consertarmos no WAL-G, ainda permanecerá no WAL-E. No WAL-E, ele analisa o status do arquivo, vê os arquivos finalizados e os arquiva, enquanto outros sistemas simplesmente não saberão que esse arquivo WAL existiu, porque o PostgreSQL não tentará arquivá-lo uma segunda vez.
O que vamos consertar aqui do lado do WAL-G? Não informaremos ao PostgreSQL que este arquivo foi transferido em paralelo, e quando o PostgreSQL nos pedir para arquivá-lo, já saberemos que tal arquivo com este modo-tempo e com este md5 já foi arquivado e diremos simplesmente PostgreSQL - OK, tudo está pronto sem fazer nada.
Mas é improvável que esse problema seja corrigido no lado do WAL-E, portanto, atualmente é impossível criar um comando de arquivamento que arquive o arquivo no WAL-G e no WAL-E.
Além disso, há casos em que o WAL-G não é adequado para você agora, mas com certeza iremos consertar.
Em primeiro lugar, atualmente não temos verificação de backup integrada. Não temos verificação durante o backup ou recuperação. Claro, isso é implementado na nuvem. Mas isso é implementado simplesmente por meio de uma pré-verificação, simplesmente pela restauração do cluster. Eu gostaria de dar essa funcionalidade aos usuários. Mas por verificação, presumo que no WAL-G será possível restaurar o cluster e iniciá-lo, e executar testes de fumaça: pg_dumpall para /dev/null e verificação de índice amcheck.
Atualmente no WAL-G não há como adiar um backup do WAL. Ou seja, apoiamos alguma janela. Por exemplo, armazenar os últimos sete dias, armazenar os últimos dez backups, armazenar os últimos três backups completos. Muitas vezes as pessoas chegam e dizem: “Precisamos de um backup do que aconteceu no Ano Novo e queremos mantê-lo para sempre”. WAL-G não pode fazer isso ainda. (Nota - Isso já foi corrigido. Leia mais - Opção de marca de backup em )
E não temos somas de verificação de página e verificações de integridade para todos os segmentos de eixo ao validar o PITR.
A partir de tudo isso montei um projeto para o Google Summer of Code. Se você conhece alunos inteligentes que gostariam de escrever algo em Go e receber vários milhares de dólares de uma empresa com a letra “G”, recomende nosso projeto a eles. Vou atuar como mentor deste projeto, eles podem fazer isso. Se não houver alunos, vou pegá-lo e fazê-lo sozinho no verão.
E temos muitos outros pequenos problemas nos quais estamos trabalhando gradualmente. E algumas coisas muito estranhas acontecem.
Por exemplo, se você fornecer um backup vazio ao WAL-G, ele simplesmente cairá. Por exemplo, se você disser a ele que ele precisa fazer backup de uma pasta vazia. O arquivo pg_control não estará lá. E ele vai pensar que não entende alguma coisa. Em teoria, neste caso você precisa escrever uma mensagem normal ao usuário para explicar como usar a ferramenta. Mas isso nem é uma característica da programação, mas sim uma característica de uma linguagem boa e inteligível.
Não sabemos como fazer backup offline. Se o banco de dados estiver mentindo, não poderemos fazer backup dele. Mas tudo é muito simples aqui. Chamamos backups pelo LSN quando começou. O LSN da base subjacente deve ser lido no arquivo de controle. E este é um recurso tão não realizado. Muitos sistemas de backup podem fazer backup de um banco de dados subjacente. E é conveniente.
Atualmente, não podemos lidar adequadamente com a falta de espaço de backup. Porque costumamos trabalhar com grandes backups em casa. E eles não tiveram tempo para isso. Mas se alguém quiser programar em Go agora, adicione ao bucket o tratamento de erros de falta de espaço. Definitivamente analisarei a solicitação pull.
E o que mais nos preocupa é que queremos o maior número possível de testes de integração do docker que verifiquem diferentes cenários. No momento, estamos testando apenas cenários básicos. Em cada commit, mas queremos verificar commit por commit todas as funcionalidades que oferecemos suporte. Em particular, por exemplo, teremos suporte suficiente para PostgreSQL 9.4-9.5. Nós os apoiamos porque a comunidade oferece suporte ao PostgreSQL, mas não verificamos commit por commit para garantir que tudo não esteja quebrado. E parece-me que este é um risco bastante sério.
Temos WAL-G rodando em mais de mil clusters no gerenciamento de banco de dados Yandex. E faz backup de centenas de terabytes de dados todos os dias.
Temos muitos TODO em nosso código. Se quiser programar, venha, estamos aguardando pull requests, estamos aguardando dúvidas.
perguntas
Boa noite! Obrigado! Meu palpite é que, se você estiver usando WAL-delta, provavelmente estará dependendo muito de gravações de página inteira. E se sim, você fez testes? Você mostrou um lindo gráfico. Quão mais bonito fica se o FPW estiver desligado?
A gravação de página inteira está habilitada para nós, não tentamos desabilitá-la. Ou seja, eu, como desenvolvedor, não tentei desligá-lo. Os administradores de sistema que pesquisaram provavelmente já pesquisaram esse problema. Mas precisamos de FPW. Quase ninguém o desativa, caso contrário é impossível fazer backup de uma réplica.
Obrigado pelo relatório! Eu tenho duas perguntas. A primeira pergunta é o que acontecerá com os tablespaces?
Estamos aguardando uma solicitação pull. Nossos bancos de dados residem em discos SSD e NMVE e realmente não precisamos desse recurso. Não estou pronto para gastar muito tempo agora fazendo isso bem. Defendo sinceramente que apoiemos isto. Há pessoas que apoiaram, mas apoiaram da forma que lhes convém. Eles fizeram um fork, mas não fazem pull requests. (Adicionado na versão 0.2.13)
E a segunda pergunta. Você disse logo no início que o WAL-G pressupõe que funciona sozinho e que nenhum wrapper é necessário. Eu mesmo uso embalagens. Por que eles não deveriam ser usados?
Queremos que seja tão simples quanto uma balalaica. Isso significa que você não precisa de nada, exceto uma balalaica. Queremos que o sistema seja simples. Se você tem funcionalidades que precisa executar em um script, venha e conte-nos - faremos isso em Go.
Boa noite! Obrigado pelo relatório! Não conseguimos fazer o WAL-G funcionar com a descriptografia GPG. Ele criptografa normalmente, mas não deseja descriptografar. É algo que não funcionou para nós? A situação é deprimente.
Crie um problema no GitHub e vamos descobrir.
Ou seja, você não encontrou isso?
Há uma característica do relatório de erros que quando o WAL-G não entende que tipo de arquivo é, ele pergunta: “Talvez esteja criptografado?” Talvez o problema não seja a criptografia. Quero melhorar o registro neste tópico. Ele deve decifrá-lo. Atualmente estamos trabalhando neste tema no sentido de que não gostamos muito da forma como está organizado o sistema de obtenção de chaves públicas e privadas. Porque chamamos GPG externo para que ele nos dê suas chaves. E então pegamos essas chaves e transferimos para o GPG interno, que é o PGP aberto, que é compilado para nós dentro do WAL-G, e aí chamamos de criptografia. Nesse sentido, queremos melhorar o sistema e oferecer suporte à criptografia Libsodium (adicionada na versão 0.2.15). Claro, a decodificação deve funcionar, vamos descobrir - você precisa de mais um sintoma do que algumas palavras. Você pode se reunir na sala do palestrante algum dia e observar o sistema. (Criptografia PGP sem GPG externo - v0.2.9)
Olá! Obrigado pelo relatório! Eu tenho duas perguntas. Tenho uma vontade estranha de fazer log pg_basebackup e WAL em dois provedores, ou seja, quero fazer uma nuvem e outra. Existe alguma maneira de fazer isso?
Isso não existe agora, mas é uma ideia interessante.
Só não confio em um provedor, quero ter o mesmo em outro, só para garantir.
A ideia é interessante. Tecnicamente, isto não é nada difícil de implementar. Para evitar que a ideia se perca, posso pedir para você criar um issue no GitHub?
Sim, é claro.
E então, quando os alunos vierem ao Google Summer of Code, iremos adicioná-los ao projeto para que haja mais trabalho para tirar mais proveito deles.
E a segunda pergunta. Há um problema no GitHub. Acho que já está fechado. Há um pânico durante a restauração. E para derrotá-lo, você fez uma montagem separada. Está certo nas questões. E existe a opção de fazer um ambiente variável em um thread. E é por isso que funciona muito lentamente. E encontramos esse problema e ainda não foi corrigido.
O problema é que por algum motivo o armazenamento (CEPH) redefine a conexão quando chegamos a ela com alta simultaneidade. O que pode ser feito sobre isso? A lógica de nova tentativa é semelhante a esta. Estamos tentando baixar o arquivo novamente. Em uma passagem tivemos vários arquivos não baixados, faremos uma segunda para todos aqueles que não fizeram login. E contanto que pelo menos um arquivo seja carregado por iteração, repetimos e repetimos e repetimos. Melhoramos a lógica de nova tentativa - espera exponencial. Mas não está totalmente claro o que fazer com o fato de a conexão simplesmente ser interrompida no lado do sistema de armazenamento. Ou seja, quando carregamos em um fluxo, essas conexões não são interrompidas. O que podemos melhorar aqui? Temos otimização de rede, podemos limitar cada conexão pelo número de bytes que ela envia. Caso contrário, não sei como lidar com o fato de que o armazenamento de objetos não nos permite fazer download ou download paralelo.
Sem SLA? Não está escrito para eles como se deixam atormentar?
A questão é que as pessoas que fazem essa pergunta geralmente têm seu próprio cofre. Ou seja, ninguém vem da Amazon, do Google Cloud ou do Yandex Object Storage.
Talvez a pergunta não seja mais para você?
A questão aqui, neste caso, não importa para quem. Se houver alguma ideia de como lidar com isso, vamos fazê-lo no WAL-G. Mas até agora não tenho boas ideias sobre como lidar com isso. Existem alguns armazenamentos de objetos que oferecem suporte à listagem de backups de maneira diferente. Você pede que eles listem os objetos e eles adicionam uma pasta lá. WAL-G fica assustado com isso - tem alguma coisa aqui que não é um arquivo, não consigo restaurá-lo, o que significa que o backup não foi restaurado. Ou seja, na verdade, você tem um cluster completamente restaurado, mas ele retorna um status errado porque o Object Storage retornou algumas informações estranhas que ele não entendeu completamente.
Isso é algo que acontece na nuvem do Mail.
Se você puder construir uma reprodução...
É reproduzido consistentemente...
Se houver uma reprodução, acho que experimentaremos estratégias de nova tentativa e descobriremos como tentar novamente e entender o que a nuvem exige de nós. Talvez seja estável para nós em três conexões e não interrompa a conexão, então chegaremos com cuidado a três. Porque agora descartamos a conexão muito rapidamente, ou seja, se lançarmos uma recuperação com 16 threads, depois da primeira tentativa haverá 8 threads, 4 threads, 2 threads e um. E então ele puxará o arquivo para um fluxo. Se houver alguns valores mágicos como 7,5 threads são os melhores para bombear, então vamos nos concentrar neles e tentar fazer outros 7,5 threads. Aqui está uma ideia.
Obrigado pelo relatório! Como é um fluxo de trabalho completo para trabalhar com WAL-G? Por exemplo, no caso estúpido em que não há delta nas páginas. E pegamos e removemos o backup inicial, depois arquivamos o eixo até ficarmos com o rosto azul. Aqui, pelo que entendi, há um colapso. Em algum momento você precisa fazer um backup delta das páginas, ou seja, algum processo externo está causando isso ou como isso acontece?
A API de backup delta é bastante simples. Há um número aí – passos delta máximos, é assim que é chamado. O padrão é zero. Isso significa que toda vez que você faz um backup push, ele baixa um backup completo. Se você alterá-lo para qualquer número positivo, por exemplo, 3, na próxima vez que você fizer um push de backup, ele examinará o histórico de backups anteriores. Ele vê que você não ultrapassa a cadeia de 3 deltas e faz um delta.
Ou seja, toda vez que lançamos o WAL-G ele tenta fazer um backup completo?
Não, nós executamos o WAL-G e ele tenta fazer um delta se suas políticas permitirem.
Grosso modo, se você executá-lo sempre com zero, ele se comportará como pg_basebackup?
Não, ele ainda rodará mais rápido porque usa compactação e paralelismo. Pg_basebackup colocará o eixo próximo a você. WAL-G assume que você configurou o arquivamento. E emitirá um aviso se não estiver configurado.
Pg_basebackup pode ser executado sem eixos.
Sim, então eles se comportarão quase da mesma forma. Pg_basebackup copia para o sistema de arquivos. A propósito, temos uma novidade que esqueci de mencionar. Agora podemos fazer backup para o sistema de arquivos de pg_basebackup. Não sei por que isso é necessário, mas está lá.
Por exemplo, no CephFS. Nem todo mundo deseja configurar o Object Storage.
Sim, provavelmente é por isso que eles fizeram uma pergunta sobre esse recurso para que pudéssemos fazê-lo. E nós fizemos isso.
Obrigado pelo relatório! Há apenas uma dúvida sobre como copiar para o sistema de arquivos. Pronto para uso, agora você oferece suporte à cópia para armazenamento remoto, por exemplo, se houver alguma prateleira no data center ou algo mais?
Nesta formulação, esta é uma questão difícil. Sim, oferecemos suporte, mas essa funcionalidade ainda não está incluída em nenhuma versão. Ou seja, todos os pré-lançamentos suportam isso, mas as versões de lançamento não. Esta funcionalidade foi adicionada na versão 0.2. Com certeza será lançado em breve, assim que corrigirmos todos os bugs conhecidos. Mas no momento isso só pode ser feito em pré-lançamento. Existem dois bugs no pré-lançamento. Problema com recuperação WAL-E, não resolvemos. E no último pré-lançamento foi adicionado um bug sobre backup delta. Portanto, recomendamos a todos que usem as versões de lançamento. Assim que não houver mais bugs no pré-lançamento, podemos dizer que oferecemos suporte ao Google Cloud, coisas compatíveis com S3 e armazenamento de arquivos.
Olá, obrigado pelo relatório. Pelo que entendi, o WAL-G não é algum tipo de sistema centralizado como o barman? Você planeja avançar nessa direção?
O problema é que nos afastamos dessa direção. O WAL-G reside no host base, no host do cluster e em todos os hosts do cluster. Quando mudamos para vários milhares de clusters, tínhamos muitas instalações de bartender. E cada vez que algo desmorona neles, é um grande problema. Como eles precisam ser reparados, você precisa entender quais clusters agora não possuem backups. Não pretendo desenvolver o WAL-G na direção de hardware físico para sistemas de backup. Se a comunidade quiser alguma funcionalidade aqui, não me importo nem um pouco.
Temos equipes responsáveis pela armazenagem. E nos sentimos tão bem que não somos nós, que existem pessoas especiais que colocam nossos arquivos onde eles estão seguros. Eles fazem todo tipo de codificação inteligente para resistir à perda de um certo número de arquivos. Eles são responsáveis pela largura de banda da rede. Quando você tem um bartender, pode descobrir de repente que pequenos bancos de dados com muito tráfego foram reunidos no mesmo servidor. Parece que você tem muito espaço, mas por algum motivo nem tudo cabe na rede. Pode acontecer o contrário. Tem muitas redes lá, tem núcleos de processador, mas não tem discos aqui. E nos cansamos dessa necessidade de fazer malabarismos e passamos à conclusão de que o armazenamento de dados é um serviço separado, pelo qual pessoas especiais são responsáveis.
PS Uma nova versão foi lançada , no qual você pode usar o arquivo de configuração .walg.json, que está localizado no diretório inicial do postgres por padrão. Você pode abandonar os scripts bash. Exemplo .walg.json está nesta edição
Vídeo:
Fonte: habr.com