Sugiro que você leia a transcrição do relatório do início de 2020 de Georgy Rylov “WAL-G: novas oportunidades e expansão da comunidade”
Os mantenedores de código aberto enfrentam muitos desafios à medida que crescem. Como escrever cada vez mais recursos necessários, corrigir cada vez mais problemas e conseguir visualizar cada vez mais solicitações pull? Usando o WAL-G (ferramenta de backup para PostgreSQL) como exemplo, contarei como resolvemos esses problemas lançando um curso de desenvolvimento de código aberto na universidade, o que alcançamos e para onde iremos a seguir.
Olá novamente a todos! Sou um desenvolvedor Yandex de Yekaterinburg. E hoje falarei sobre o WAL-G.
O título do relatório não dizia que se tratava de backups. Alguém sabe o que é WAL-G? Ou todo mundo sabe? Levante a mão se você não sabe. Puta merda, você veio até a reportagem e não sabe do que se trata.
Deixe-me contar o que vai acontecer hoje. Acontece que nossa equipe já faz backups há algum tempo. E este é outro relatório de uma série onde falamos sobre como armazenamos dados de forma segura, conveniente e eficiente.
Nas séries anteriores, houve muitos relatos de Andrei Borodin e Vladimir Leskov. Éramos muitos. E já falamos sobre o WAL-G há muitos anos.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Este relatório será um pouco diferente dos outros por tratar mais da parte técnica, mas aqui falarei sobre como encontramos problemas associados ao crescimento da comunidade. E como tivemos uma pequena ideia que nos ajuda a lidar com isso.
Há alguns anos, o WAL-G era um projeto bastante pequeno que obtivemos da Citus Data. E nós simplesmente pegamos. E foi desenvolvido por uma pessoa.
E só o WAL-G não tinha:
- Backup de uma réplica.
- Não houve backups incrementais.
- Não houve backups WAL-Delta.
- E ainda faltava muita coisa.
Ao longo desses anos, o WAL-G cresceu muito.
E em 2020, todos os itens acima já apareceram. E a isso foi adicionado o que temos agora:
- Mais de 1 estrelas no GitHub.
- 150 garfos.
- Cerca de 15 PRs abertos.
- E muitos mais colaboradores.
- E questões abertas o tempo todo. E isso apesar de literalmente irmos lá todos os dias e fazermos algo a respeito.
E chegamos à conclusão de que este projeto requer mais atenção, mesmo quando nós mesmos não precisamos implementar nada para nosso serviço de Bancos de Dados Gerenciados no Yandex.
E em algum momento do outono de 2018, uma ideia veio à nossa mente. Normalmente a equipe tem várias maneiras de desenvolver alguns recursos ou corrigir bugs caso você não tenha mãos suficientes. Por exemplo, você pode contratar outro desenvolvedor e pagar-lhe dinheiro. Ou você pode contratar um estagiário por um tempo e também pagar-lhe algum salário. Mas ainda existe um grupo bastante grande de pessoas, algumas das quais já sabem realmente escrever código. Você nem sempre sabe qual é a qualidade do código.
Pensamos nisso e decidimos tentar atrair alunos. Mas os alunos não participarão de tudo conosco. Eles farão apenas uma parte do trabalho. E eles irão, por exemplo, escrever testes, corrigir bugs, implementar recursos que não afetam a funcionalidade principal. A principal funcionalidade é criar backups e restaurar backups. Se cometermos um erro ao criar um backup, sofreremos perda de dados. E ninguém quer isso, é claro. Todo mundo quer que tudo seja muito seguro. Portanto, é claro, não queremos permitir códigos em que confiamos menos do que os nossos. Ou seja, qualquer código não crítico é o que gostaríamos de receber dos nossos trabalhadores adicionais.
Em que condições a RP estudantil é aceita?
- Eles são obrigados a cobrir seu código com testes. Tudo deve acontecer no CI.
- E também passamos por 2 avaliações. Um de Andrey Borodin e outro meu.
- E além disso, para verificar se isso não irá quebrar nada em nosso serviço, carrego separadamente o assembly com este commit. E verificamos em testes ponta a ponta se nada falha.
Curso especial sobre código aberto
Um pouco sobre por que isso é necessário e por que me parece uma ideia legal.
Para nós, o lucro é óbvio:
- Conseguimos mãos extras.
- E estamos procurando candidatos para a equipe entre estudantes inteligentes que escrevem códigos inteligentes.
Qual é o benefício para os alunos?
Eles podem ser menos óbvios, porque os alunos, no mínimo, não recebem dinheiro pelo código que escrevem, mas apenas recebem notas pelos seus registros estudantis.
Eu perguntei a eles sobre isso. E nas palavras deles:
- Experiência de contribuidor em Open Source.
- Coloque uma linha em seu currículo.
- Prove seu valor e passe em uma entrevista no Yandex.
- Torne-se um membro do GSoC.
- +1 curso especial para quem quer escrever código.
Não vou falar sobre como o curso foi estruturado. Direi apenas que o WAL-G foi o projeto principal. Também incluímos projetos como Odyssey, PostgreSQL e ClickHouse neste curso.
E deram problemas não só nesse curso, mas também distribuíram diplomas e cursos.
E quanto ao benefício para os usuários?
Agora vamos para a parte que mais lhe interessa. Que bem isso lhe traz? A questão é que os alunos consertaram muitos bugs. E fizemos as solicitações de recursos que você nos pediu.
E deixe-me contar sobre as coisas que você deseja há muito tempo e que foram realizadas.
Suporte a espaços de tabela. Tablespaces no WAL-G eram esperados provavelmente desde o lançamento do WAL-G, porque o WAL-G é o sucessor de outra ferramenta de backup WAL-E, onde eram suportados backups de banco de dados com tablespaces.
Deixe-me lembrá-lo brevemente o que é e por que é necessário. Normalmente, todos os seus dados do Postgres ocupam um diretório no sistema de arquivos, chamado base. E este diretório já contém todos os arquivos e subdiretórios exigidos pelo Postgres.
Tablespaces são diretórios que contêm dados do Postgres, mas não estão localizados fora do diretório base. O slide mostra que os tablepacs estão localizados fora do diretório base.
Como é isso para o próprio Postgres? Existe um subdiretório separado pg_tblspc no diretório base. E contém links simbólicos para diretórios que realmente contêm dados do Postgres fora do diretório base.
Quando você usa tudo isso, para você esses comandos podem ser parecidos com isto. Ou seja, você cria uma tabela em algum espaço de tabela especificado e vê onde ela está agora. Estas são as duas últimas linhas, os dois últimos comandos chamados. E aí está claro que existe algum caminho. Mas, na realidade, este não é o verdadeiro caminho. Este é o caminho prefixado do diretório base para o espaço de tabela. E a partir daí ele é combinado com um link simbólico que leva aos seus dados reais.
Não usamos tudo isso em nossa equipe, mas foi usado por muitos outros usuários do WAL-E que nos escreveram dizendo que queriam migrar para o WAL-G, mas isso os estava impedindo. Isso agora é suportado.
Outra funcionalidade que nosso curso especial nos trouxe é o catchup. Pessoas que provavelmente trabalharam mais com Oracle do que com Postgres sabem sobre catchup.
Resumidamente sobre o que é. A topologia de cluster em nosso serviço geralmente pode ser semelhante a esta. Nós temos um mestre. Há uma réplica que transmite o log write-ahead dele. E a réplica informa ao mestre em qual LSN ela está atualmente. E em algum lugar paralelo a isso, o log pode ser arquivado. E além de arquivar o log, os backups também são enviados para a nuvem. E os backups delta são enviados.
Qual poderia ser o problema? Quando você tem um banco de dados bastante grande, pode acontecer que sua réplica comece a ficar muito atrás do mestre. E ela está tão atrasada que nunca consegue alcançá-lo. Esse problema geralmente precisa ser resolvido de alguma forma.
E a maneira mais fácil é remover a réplica e carregá-la novamente, porque ela nunca será atualizada e o problema precisa ser resolvido. Mas isso é muito tempo, porque restaurar um backup inteiro de banco de dados de 10 TB é muito, muito longo. E queremos fazer tudo isso o mais rápido possível caso surjam problemas desse tipo. E é exatamente para isso que serve o catchup.
Catchup permite que você use backups delta, que são armazenados na nuvem dessa forma. Você diz em qual LSN a réplica atrasada está atualmente e especifica-a no comando catchup para criar um backup delta entre esse LSN e o LSN no qual seu cluster está localizado atualmente. E depois disso você restaura esse backup para a réplica que estava atrasada.
Outras bases
Os alunos também nos trouxeram muitos recursos ao mesmo tempo. Como no Yandex cozinhamos não só Postgres, também temos MySQL, MongoDB, Redis, ClickHouse, em algum momento precisávamos ser capazes de fazer backups com recuperação point-in-time para MySQL, e para que houvesse a oportunidade de fazer upload -los para a nuvem.
E queríamos fazer isso de uma forma semelhante ao que o WAL-G faz. E decidimos experimentar e ver como tudo ficaria.
E a princípio, sem compartilhar de forma alguma essa lógica, eles escreveram o código no fork. Eles viram que temos algum tipo de modelo funcional e ele pode voar. Aí pensamos que nossa comunidade principal é o postgresists, eles usam WAL-G. E, portanto, precisamos separar de alguma forma essas partes. Ou seja, quando editamos o código do Postgres, não quebramos o MySQL; quando editamos o MySQL, não quebramos o Postgres.
A primeira ideia de como separar isso foi a ideia de usar a mesma abordagem que é usada nas extensões do PostgreSQL. E, de fato, para fazer um backup do MySQL era necessário instalar algum tipo de biblioteca dinâmica.
Mas aqui a assimetria desta abordagem é imediatamente visível. Ao fazer backup do Postgres, você coloca um backup normal do Postgres nele e está tudo bem. E para MySQL acontece que você instala um backup para Postgres e também instala uma biblioteca dinâmica para MySQL para ele. Parece meio estranho. Nós também pensamos assim e decidimos que esta não era a solução que precisávamos.
Várias compilações para Postgres, MySQL, MongoDB, Redis
Mas isso nos permitiu, ao que parece, tomar a decisão certa - alocar diferentes montagens para diferentes bases. Isso permitiu isolar a lógica vinculada aos backups dos diversos bancos de dados que acessarão a API comum que o WAL-G implementa.
Esta é a parte que nós mesmos escrevemos - antes de entregar os problemas aos alunos. Ou seja, essa é exatamente a parte em que eles poderiam fazer algo errado, então decidimos que seria melhor fazermos algo assim e tudo ficará bem.
Depois disso, distribuímos problemas. Eles foram imediatamente desmontados. Os alunos foram obrigados a apoiar três bases.
Este é o MySQL, do qual fazemos backup usando WAL-G dessa forma há mais de um ano.
E agora o MongoDB está se aproximando da produção, onde está finalizando com um arquivo. Na verdade, escrevemos a estrutura para tudo isso. Em seguida, os alunos escreveram algumas coisas viáveis. E então os levamos a um estado que podemos aceitar na produção.
Esses problemas não pareciam exigir que os alunos escrevessem ferramentas completas de backup para cada um desses bancos de dados. Não tivemos esse problema. Nosso problema era que queríamos uma recuperação pontual e fazer backup na nuvem. E pediram aos alunos que escrevessem algum código que resolvesse isso. Os alunos usaram ferramentas de backup já existentes, que de alguma forma fazem backups, e depois colaram tudo com o WAL-G, que encaminhou tudo para a nuvem. E eles também adicionaram recuperação pontual a isso.
O que mais os alunos trouxeram? Eles trouxeram suporte à criptografia Libsodium para o WAL-G.
Também temos políticas de armazenamento de backup. Agora os backups podem ser marcados como permanentes. E de alguma forma é mais conveniente para o seu serviço automatizar o processo de armazenamento.
Qual foi o resultado deste experimento?
Mais de 100 pessoas se inscreveram inicialmente no curso. A princípio eu não disse que a universidade de Yekaterinburg é a Universidade Federal dos Urais. Anunciamos tudo lá. 100 pessoas cadastradas. Na realidade, muito menos pessoas começaram a fazer alguma coisa, cerca de 30 pessoas.
Menos ainda pessoas concluíram o curso, porque foi necessário escrever testes para os códigos que já existem. E também corrija algum bug ou crie algum recurso. E alguns alunos ainda fecharam o curso.
Atualmente, durante este curso, os alunos consertaram cerca de 14 questões e fizeram 10 recursos de diversos tamanhos. E, parece-me, esta é uma substituição completa de um ou dois desenvolvedores.
Entre outras coisas, emitimos diplomas e cursos. E 12 receberam diplomas. 6 deles já se defenderam em “5”. Os que ficaram ainda não tinham proteção, mas acho que para eles também vai ficar tudo bem.
Planos para o futuro
Que planos temos para o futuro?
Pelo menos aquelas solicitações de recursos que já ouvimos dos usuários e queremos fazer. Esse:
- Monitorando a exatidão do rastreamento da linha do tempo no arquivo de backup do cluster HA. Você pode fazer isso com WAL-G. E acho que teremos alunos que vão abordar esse assunto.
- Já temos um responsável pela transferência de backups e WAL entre nuvens.
- E recentemente publicamos a ideia de que podemos acelerar ainda mais o WAL-G descompactando backups incrementais sem reescrever páginas e otimizando os arquivos que enviamos para lá.
Você pode compartilhá-los aqui
Para que serviu este relatório? Além disso, agora, além das 4 pessoas que apoiam este projeto, temos mãos adicionais, que são bastante. Especialmente se você escrever para eles uma mensagem pessoal. E se você fizer backup de seus dados e fizer isso usando WAL-G ou quiser migrar para WAL-G, podemos facilmente atender aos seus desejos.
Este é um código QR e um link. Você pode percorrê-los e escrever todos os seus desejos. Por exemplo, não estamos corrigindo algum bug. Ou você realmente quer algum recurso, mas por algum motivo ele ainda não está em nenhum backup, inclusive o nosso. Certifique-se de escrever sobre isso.
perguntas
Olá! Obrigado pelo relatório! Pergunta sobre o WAL-G, mas não sobre o Postgres. WAL-G faz backup do MySQL e chama um backup extra. Se fizermos instalações modernas no CentOS e você instalar o MySQL, o MariDB será instalado. A partir da versão 10.3, o backup extra não é suportado, o backup MariDB é suportado. Como você está se saindo com isso?
No momento não tentamos fazer backup do MariDB. Recebemos solicitações de suporte do FoundationDB, mas em geral, se houver tal solicitação, poderemos encontrar pessoas que o farão. Não é tão longo ou tão difícil quanto penso.
Boa tarde Obrigado pelo relatório! Pergunta sobre possíveis novos recursos. Você está pronto para fazer o WAL-G funcionar com fitas para poder fazer backup em fitas?
Aparentemente, backup em armazenamento em fita significa?
Sim.
Existe Andrei Borodin, que pode responder a essa pergunta melhor do que eu.
(Andrey) Sim, obrigado pela pergunta! Recebemos uma solicitação para transferir um backup para fita do armazenamento em nuvem. E para isso transferência entre nuvens. Porque a transferência de nuvem para nuvem é uma versão generalizada da transferência de fita. Além disso, temos uma arquitetura extensível em termos de Storages. A propósito, muitos Storoges foram escritos por estudantes. E se você escrever Armazenamento para fita, então, é claro, ele será suportado. Estamos prontos para considerar solicitações pull. Lá você precisa escrever um arquivo, ler um arquivo. Se você fizer essas coisas em Go, geralmente terá 50 linhas de código. E então a fita será suportada no WAL-G.
Obrigado pelo relatório! Processo de desenvolvimento interessante. O backup é uma funcionalidade séria que deve ser bem coberta pelos testes. Quando você implementou funcionalidades para novos bancos de dados, os alunos também escreveram os testes ou você mesmo escreveu os testes e depois entregou a implementação aos alunos?
Os alunos também escreveram testes. Mas os estudantes escreveram mais sobre recursos como novos bancos de dados. Eles escreveram testes de integração. E eles escreveram testes unitários. Se a integração passar, ou seja, no momento, esse é um script que você executa manualmente ou tem o cron fazendo isso, por exemplo. Ou seja, o roteiro aí é muito claro.
Os alunos não têm muita experiência. A revisão leva muito tempo?
Sim, as revisões levam muito tempo. Isto é, normalmente, quando vários committers vêm ao mesmo tempo e dizem que eu fiz isso, eu fiz aquilo, então você precisa pensar e reservar cerca de meio dia para descobrir o que eles escreveram lá. Porque o código deve ser lido com atenção. Eles não tiveram entrevista. Não os conhecemos muito bem, por isso leva um tempo significativo.
Obrigado pelo relatório! Anteriormente, Andrey Borodin afirmou que archive_command no WAL-G deveria ser chamado diretamente. Mas no caso de algum tipo de cartucho cluster, precisamos de lógica adicional para determinar o nó de onde enviar os eixos. Como você resolve esse problema sozinho?
Qual é o seu problema aqui? Digamos que você tenha uma réplica síncrona com a qual está fazendo backup? Ou o que?
(Andrey) O fato é que de fato o WAL-G foi projetado para ser usado sem shell scripts. Se faltar alguma coisa, vamos adicionar a lógica que deveria estar dentro do WAL-G. Quanto à origem do arquivamento, acreditamos que o arquivamento deve ser do mestre atual do cluster. Arquivar a partir de uma réplica é uma má ideia. Existem vários cenários possíveis com problemas. Em particular, problemas com prazos de arquivamento e quaisquer informações adicionais. Obrigado pela pergunta!
(Esclarecimento: nos livramos dos scripts de shell )
Boa noite! Obrigado pelo relatório! Estou interessado no recurso de catchup de que você falou. Enfrentamos uma situação em que uma réplica estava atrasada e não conseguia alcançá-la. E não encontrei descrição desse recurso nos documentos WAL-G.
Catchup apareceu literalmente no dia 20 de janeiro de 2020. A documentação pode precisar de mais algum trabalho. Nós mesmos escrevemos e não escrevemos muito bem. E talvez devêssemos começar a exigir que os alunos o escrevessem.
Já foi lançado?
A solicitação pull já está morta, ou seja, eu verifiquei. Eu tentei isso em um cluster de teste. Até agora não tivemos uma situação em que pudéssemos testar isto num exemplo de combate.
Quando esperar?
Não sei. Espere um mês, vamos verificar com certeza.
Fonte: habr.com