Kafka-backup: Compensação do consumidor

Olá Imran,

Estou escrevendo uma postagem no blog sobre backup e restauração de Kafka Topics em um ambiente Kubernetes com outro projeto de código aberto OpenEBS fornecendo o armazenamento anexado ao contêiner persistente subjacente.

Fazer backup do Kafka usando instantâneos do sistema de arquivos não é tão trivial. Consulte https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md para obter mais informações sobre isso.

Por enquanto, decidi usar o conector S3 do Spredfast, mas meu amigo Arash Kaffamanesh me indicou seu trabalho. Eu tinha algumas perguntas.

O conector S3 parece perfeitamente adequado se você não precisar restaurar nenhum deslocamento do consumidor. Mergulhei profundamente no código-fonte do conector S3 antes de descartá-lo como uma solução para nossos problemas, pois ele não fornece esse recurso crítico e é difícil estendê-lo para lidar com esse caso.

No momento da restauração, como faço para informar ao consumidor por onde começar a consumir?

Atualmente, a única maneira é apenas excluir os segmentos que não devem ser restaurados e recriar o índice. Em breve haverá mais informações sobre como conseguir isso. Se você realmente precisar iniciar a restauração a partir de um deslocamento muito específico, abra um problema. Isso não deve ser difícil de implementar.

Você pode compartilhar diferenças adicionais com o conector do spredfast?

Novamente, o conector S3 não consegue sincronizar os deslocamentos do consumidor durante a restauração. Na verdade, simplesmente não há como fazer isso de forma confiável na versão atual do Kafka. Graças ao trabalho de @ryannedolan no Mirror Maker 2 , em breve haverá uma maneira de fazer isso e kafka-backup usa essa API. Felizmente, essa mudança é compatível com versões anteriores e haverá documentação sobre como usar kafka-backup dessa maneira muito em breve.

Além disso, o S3 Connector apenas suporta S3. Atualmente kafka-backup suporta apenas backup para sistema de arquivos e, em seguida, você pode usar qualquer ferramenta que desejar para movê-lo para seu destino final. Estou planejando adicionar suporte para mais back-ends de armazenamento, se houver necessidade.

Além disso, os dois projetos são muito semelhantes em termos de arquitetura (na verdade, o conector S3 junto com o Mirror Maker 2 inspirou kafka-backup )

meu ambiente Kafka é executado no Kubernetes. Idealmente, eu quero um local de armazenamento de backup/restauração fora do meu cluster para que eu possa recuperá-lo em caso de falha.

Até onde eu sei você está usando Strimzi também, nós temos o mesmo backup. Em breve escreverei um post no blog sobre como fazer um backup completo do Kafka e (não se esqueça disso!) Zookeeper no Kubernetes e Strimzi.

o local de backup é determinado por target.dir , torna-se difícil gerenciar um caminho em um nó se o ambiente for Kubernetes.

Basta montar um volume persistente como sempre. Use um contêiner sidecar para movê-lo para seu destino final. Você pode até manter o volume persistente relativamente pequeno, pois pode excluir segmentos antigos e seu índice assim que forem finalizados. (A documentação está chegando)

Se você esperar mais alguns dias, publicarei um post introdutório no blog cobrindo alguns de seus tópicos. Escreva-me um e-mail ou peça a @arashkaffamanesh um rascunho :wink:

A contribuição da @azapps é única e incrível e acho que toda a comunidade deve ajudar a fazer com que o Kafka Backup proposto e implementado pela @azapps se torne uma peça padronizada do Kafka Ecosystem!

Nada é perfeito, mas essa implementação da @azapps é brilhante!

Para o registro: Aqui vamos nós: https://medium.com/@anatolyz/introducing -kafka-backup-9dc0677ea7ee