Kafka-backup: Compensación del consumidor

Hola Imran,

Estoy escribiendo una publicación de blog sobre la copia de seguridad y la restauración de los temas de Kafka en un entorno de Kubernetes con otro proyecto de código abierto, OpenEBS, que proporciona el almacenamiento adjunto del contenedor persistente subyacente.

Hacer una copia de seguridad de Kafka usando instantáneas del sistema de archivos no es tan trivial. Consulte https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md para obtener más información al respecto.

Por ahora me decidí por usar el conector S3 de Spredfast, pero mi amigo Arash Kaffamanesh me indicó tu trabajo. Tenía un par de preguntas.

El conector S3 parece estar perfectamente bien si no necesita restaurar ninguna compensación del Consumidor. Me sumergí profundamente en el código fuente del conector S3 antes de descartarlo como una solución para nuestros problemas, ya que no proporciona esa característica crítica y es difícil extenderlo para manejar ese caso.

En el momento de la restauración, ¿cómo le hago saber al consumidor desde dónde empezar a consumir?

Actualmente, la única forma es simplemente eliminar los segmentos que no deben restaurarse y volver a crear el índice. Pronto habrá más información sobre cómo lograrlo. Si realmente necesita iniciar la restauración desde un desplazamiento muy específico, abra un problema. Eso no debería ser difícil de implementar.

¿Puede compartir diferencias adicionales con el conector de spredfast?

Nuevamente, el conector S3 no puede sincronizar las compensaciones de los consumidores durante la restauración. De hecho, simplemente no hay forma de hacerlo de manera confiable en la versión actual de Kafka. Gracias al trabajo de @ryannedolan en Mirror Maker 2 , pronto habrá una manera de hacerlo y kafka-backup usa esa API. Afortunadamente, este cambio es incluso compatible con versiones anteriores y habrá documentación sobre cómo usar kafka-backup esa manera muy pronto.

Además, S3 Connector solo es compatible con S3. Actualmente kafka-backup solo admite copias de seguridad en el sistema de archivos y luego puede usar cualquier herramienta que desee para moverlo a su destino final. Estoy planeando agregar soporte para más backends de almacenamiento si es necesario.

Aparte de eso, los dos proyectos son arquitectónicamente muy similares (de hecho, el conector S3 junto con Mirror Maker 2 inspiraron kafka-backup )

mi entorno de Kafka se ejecuta en Kubernetes. Idealmente, quiero una ubicación de almacenamiento de copia de seguridad/restauración fuera de mi clúster para poder recuperarla en caso de falla.

Por lo que sé, también está usando Strimzi, tenemos la misma copia de seguridad. Escribiré una publicación de blog pronto sobre cómo hacer una copia de seguridad completa de Kafka y (¡no lo olviden!) Zookeeper en Kubernetes y Strimzi.

la ubicación de la copia de seguridad está determinada por target.dir , se vuelve difícil administrar una ruta en un nodo si el entorno es Kubernetes.

Simplemente monte un volumen persistente como siempre. Use un contenedor sidecar para moverlo a su destino final. Incluso puede mantener el volumen persistente relativamente pequeño, ya que puede eliminar los segmentos antiguos y su índice tan pronto como finalicen. (La documentación está llegando)

Si espera unos días más, publicaré una entrada de blog introductoria que cubrirá algunos de sus temas. Escríbeme un correo electrónico o pídele a @arashkaffamanesh un borrador :wink:

La contribución de @azapps es única e impresionante, y creo que toda la comunidad debería ayudar a que la copia de seguridad de Kafka propuesta e implementada por @azapps se convierta en una pieza estandarizada del ecosistema de Kafka.

¡Nada es perfecto, pero esta implementación de @azapps es brillante!

Para que conste: Aquí vamos: https://medium.com/@anatolyz/introducing -kafka-backup-9dc0677ea7ee