Tiene razón con respecto al procedimiento de restauración. Restaurar es una actividad única.
La copia de seguridad es una actividad que se ejecuta continuamente. No hay "Terminé de hacer una copia de seguridad" en Kafka, ya que los datos de Kafka son un flujo y no tienen fin. Claro, puede suponer que si no obtuvo ningún dato nuevo durante x segundos, está "listo", pero no puede generalizar eso.
Eche un vistazo a los números 46 y 54 para obtener más información.

56: entonces:

@itadventurer

La copia de seguridad es una actividad que se ejecuta continuamente.

Esto supone un flujo continuo de datos las 24 horas del día, los 7 días de la semana, los 365 días del año, lo que no se aplica a todos los casos. En nuestro caso, la transmisión se ejecuta solo durante X horas por día, la copia de seguridad ocurre solo después de eso y en realidad está pensada como una copia de seguridad / instantánea diaria de los datos.

Creo que debería haber una forma de detectar (internamente) que no ha habido ningún mensaje nuevo durante X cantidad de tiempo (posiblemente intervalo configurable) después del cual el proceso de copia de seguridad saldría con gracia y, por lo tanto, finalizaría el proceso.

Otra alternativa (posiblemente más simple) a esto sería hacer una copia de seguridad de los mensajes hasta la fecha en que se inició la copia de seguridad. No estoy seguro de cómo funcionaría esto junto con las compensaciones de respaldo. Tal vez primero hagamos una copia de seguridad de las compensaciones, luego conocemos la marca de tiempo en la que hicimos la copia de seguridad de las compensaciones y podemos hacer una copia de seguridad de los mensajes hasta esa marca de tiempo.

Te entiendo. Sí, probablemente sería bueno tener una forma de hacer copias de seguridad en un momento determinado: pensar:
Sin embargo, esto no es trivial, ya que no hay una manera fácil de decidir si una transmisión "terminó".

Qué puedes hacer en tu caso:

• Deje que Kafka Backup se ejecute en segundo plano
• Kafka Backup escribe datos continuamente en segundo plano en el sistema de archivos
• kill -9 Kafka Realice una copia de seguridad tan pronto como esté "terminado", es decir, haya terminado de escribir sus datos. Esto debe hacerse inmediatamente después de que haya terminado de producir datos.
• Mueva los datos de Kafka Backup a su nuevo destino.

Entiendo que este es un caso de uso bastante común y proporcionaré más documentación para eso con el n. ° 2. Para v0.1, la documentación es el último gran problema, así que espero que esto suceda pronto;)

Veo el siguiente enfoque

• # 54 presenta una nueva herramienta CLI independiente. La herramienta CLI debería admitir esto.
• Agregamos una nueva marca --snapshot a la herramienta CLI (o agregamos una nueva herramienta llamada backup-snapshot.sh )

Cómo detectar cuándo una copia de seguridad está "terminada" (solo se aplica si se establece la --snapshot ):

• Recordamos el momento en que se inicia la copia de seguridad. Todos los registros que tienen una marca de tiempo más reciente se ignoran durante la copia de seguridad.
• Cuando una partición no produce ningún dato nuevo durante algún tiempo (por ejemplo, 20 s) asumimos que no hay datos nuevos

¿Qué piensas?

Deje que Kafka Backup se ejecute en segundo plano

El problema está exactamente en este paso. No podemos mantenerlo funcionando en segundo plano. Solo tenemos una ventana específica cuando podemos hacer la instantánea. No nos corresponde a nosotros decidir cuándo podemos hacer una copia de seguridad, se trata de requisitos regulatorios externos.

Recordamos el momento en que se inicia la copia de seguridad. Todos los registros que tienen una marca de tiempo más reciente se ignoran durante la copia de seguridad.

Sí, eso es exactamente lo que quise decir y creo que esto eliminaría el requisito de tenerlo ejecutándose en segundo plano (y tratar de captar el momento en que todos los productores terminan).

Cuando una partición no produce ningún dato nuevo durante algún tiempo (por ejemplo, 20 s) asumimos que no hay datos nuevos

Creo que esta opción es mutuamente exclusiva con la otra. Y creo que el primero es mejor, ya que proporciona un punto de referencia específico y no se basa en encontrar una ventana cuando no hay mensajes.

En realidad, quería escribir que esto es casi imposible con Kafka, pero mientras escribía tuve una idea para una solución:

kafka-consumer-groups devuelve la posición actual del consumidor en la partición, pero lo más interesante es que devuelve el desplazamiento final actual de cada partición en particular. Esto significa que hay una forma de obtener el último desplazamiento de una partición en un momento determinado. Actualmente no tengo idea de cómo se logra esto (necesito verificar el código).

Así que ahora hay una ruta clara sobre cómo hacer una copia de seguridad (más o menos) en un momento determinado:

1. Obtenga el desplazamiento de fin de partición para cada partición de la que se hará una copia de seguridad (en algún lugar aquí: https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink /BackupSinkTask.java#L81)
2. Consume cada partición
3. Tan pronto como un registro consumido tenga una compensación >= el guardado para esa partición, recuerde esto. Ignore todos los registros de la copia de seguridad. (Ver https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink/BackupSinkTask.java#L63)
4. Tan pronto como todas las particiones estén actualizadas, imprima un mensaje en STDOUT
5. Utilice la secuencia de comandos de envoltura para detectar este mensaje y matar a kafka connect sin problemas. Similar a cómo se resuelve durante la restauración: https://github.com/itadventurer/kafka-backup/blob/master/bin/restore-standalone.sh#L232 -L252

Verá que esto no es tan trivial.

Mi objetivo actual es mejorar el conjunto de pruebas y estabilizar Kafka Backup para una primera versión (consulte https://github.com/itadventurer/kafka-backup/milestone/1). No puedo darte una ETA para esa función. Estaría más que feliz de revisar un PR para eso (y también estoy buscando mantenedores adicionales;)) Estoy feliz de ayudar si hay alguna pregunta

Verá que esto no es tan trivial.

Estoy más en el lado de las operaciones (como configurar, monitorear clústeres de Kafka, etc.). Así que confío en ti en esta parte. Mi punto es que desde mi lado del trabajo esto es algo que yo (y bastante seguro que muchos otros) necesito.

Estaría más que feliz de revisar un PR para eso (y también estoy buscando mantenedores adicionales;))

No soy tan bueno con Java / Scala para ser de mucha ayuda aquí. Si fuera Python, C / C ++ o al menos Go, podría ayudar: P

¡Hola!
al principio, estoy feliz de encontrar su solución, porque tengo que hacer una copia de seguridad de los datos del tema de kafka
en segundo lugar, desafortunadamente no pude escribir nada en Java / Scala, así que preparé un 'contenedor' para usted 'backup-standalone.sh' con python para una solución de copia de seguridad completa
https://gist.github.com/FloMko/7adf2e00cd80fe7cc88bb587cde999ce
Será bueno ver las actualizaciones sobre cualquier soporte integrado para la copia de seguridad en un momento determinado

Oye,
¡Gracias por tu trabajo! Como solución temporal, podría imaginar agregar esto como un script adicional a este repositorio y reemplazarlo más tarde por una solución incorporada. Siéntase libre de agregar esto como una solicitud de extracción :) (a ./bin/kafka-backup-point-in-time.py o algo más;))

Estoy a punto de publicar una implementación completamente separada escrita en Go que no depende de la API de conexión. Solo para tu información. Ya lo estamos utilizando en nuestro entorno de producción.

@akamensky, ¿ podrías compartir tu solución? en la medida en que haya probado su solución, estará bien

@FloMko lo acabamos de publicar. Puede encontrarlo (así como un binario reconstruido) aquí

¡Gracias @WesselVS por su PR # 99! Lo acabo de fusionar para dominar. Hará un lanzamiento con esta mejora y algunas otras correcciones pronto.

@akamensky ¡Genial! Genial ver más trabajo con respecto a Kafka Backups;)