Kafka-backup: Sin embargo, otra NPE

Creado en 17 mar. 2020 · 16Comentarios · Fuente: itadventurer/kafka-backup

Simplemente ingrese a NPE a continuación ayer (usando la confirmación 3c95089c). Probé hoy con la última confirmación del maestro (f30b9ad9), aunque todavía está aquí. El resultado a continuación es de la última versión.

¿Qué ha cambiado? Hice la migración a eCryptfs. Detuve kafka-backup, renombré directorio de destino, vacié y chattr +i 'd configuración del sumidero de respaldo (para evitar que Puppet inicie kafka-backup nuevamente). Luego implementé los cambios de eCryptfs, hice rsync de nuevo, luego lo des- chattr +i 'd y volví a aplicar Puppet.

Ahora la pregunta principal, ¿deberíamos intentar depurar esto? ¿O debería borrarlo y hacer otra copia de seguridad nueva? Esto es QA, así que tenemos algo de tiempo por si acaso.

[2020-03-17 02:23:47,321] INFO [Consumer clientId=connector-consumer-chrono_qa-backup-sink-0, groupId=connect-chrono_qa-backup-sink] Setting offset for partition [redacted].chrono-billable-datasink-0 to the committed offset FetchPosition{offset=0, offsetEpoch=Optional.empty, currentLeader=LeaderAndEpoch{leader=kafka5.node:9093 (id: 5 rack: null), epoch=187}} (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator:762)
[2020-03-17 02:23:47,697] ERROR WorkerSinkTask{id=chrono_qa-backup-sink-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask:179)
java.lang.NullPointerException
        at de.azapps.kafkabackup.sink.BackupSinkTask.close(BackupSinkTask.java:122)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:397)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.closePartitions(WorkerSinkTask.java:591)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:196)
        at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:177)
        at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:227)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)
[2020-03-17 02:23:47,705] ERROR WorkerSinkTask{id=chrono_qa-backup-sink-0} Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:180)
[2020-03-17 02:23:47,705] INFO Stopped BackupSinkTask (de.azapps.kafkabackup.sink.BackupSinkTask:139)

bug

Fuente

jay7x

Todos 16 comentarios

JFYI, lo borré y comencé con una copia de seguridad nueva. No dude en cerrar este problema.

jay7x en 20 mar. 2020

Hmm… Esto es extraño… Las líneas de código relevantes son estas aquí: https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/Sink/askupja # L121 -L122

partitionWriters se completan en la llamada open() en https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink BackupSinkTask.java # L107
Que se llama por cada TopicPartition para abrir ... No tiene sentido para mí por qué sucede esto :(

¿Tiene sus datos todavía disponibles para una mayor depuración? Sería interesante intentar reproducirlo. Al menos deberíamos mostrar un error significativo en lugar de simplemente lanzar una NPE ...

itadventurer en 21 mar. 2020

¡Hola! Sí, todavía tengo una copia de seguridad del directorio antiguo. Aunque su uso puede afectar el estado actual de la copia de seguridad del clúster, supongo que no cambié el nombre del receptor.

jay7x en 23 mar. 2020

Supongo que este directorio de destino se rompió de alguna manera durante los intentos de habilitación de eCryptfs. Quizás algún archivo se cambió accidentalmente o algo así.

jay7x en 23 mar. 2020

Hmm… ¿Contiene información sensible? Si no, no dude en subirlo a https://send.firefox.com/ y enviarme un enlace. Intentaría reproducir el error.
De lo contrario, puede intentar reproducirlo con un clúster nuevo o cerramos el problema por ahora esperando que tenga razón;)

itadventurer en 23 mar. 2020

También sucedió hoy en otro grupo ...
Tengo un cronjob de copia de seguridad de Azure que detiene kafka-backup, luego desmonta eCryptfs, luego hace azcopy sync , luego vuelve a montar eCryptfs e inicia kafka-backup.
Esta noche el paso umount falló, por lo que el script también falló ( set -e ). Supongo que este es el momento en que ocurre el problema. Aunque necesito volver a comprobar la línea de tiempo con cuidado. Actualizará este problema más tarde.

UPD. Hice una comprobación de registros hace un momento. La NPE ocurrió antes en realidad. Kafka-backup fue eliminado por OOM varias veces ... Parece que -Xmx1024M o Docker memory_limit=1152M no es suficiente para este clúster :( Alguna idea sobre cómo calcular el tamaño de HEAP / RAM para kafka-backup ?

¿Quieres que depure un poco estos datos? No puedo subirlo porque contiene datos confidenciales de la empresa ...

jay7x en 24 mar. 2020

👍1

Por cierto, ¿el sumidero fallido puede hacer que kafka-connect salga? Sería bueno si todo el proceso de conexión independiente fallara en caso de falla de un solo sumidero (cuando no existe otro sumidero / conector).

jay7x en 27 mar. 2020

Por cierto, ¿el sumidero fallido puede hacer que kafka-connect salga? Sería bueno si todo el proceso de conexión independiente fallara en caso de falla de un solo sumidero (cuando no existe otro sumidero / conector).
Ver # 46

UPD. Hice una comprobación de registros hace un momento. La NPE ocurrió antes en realidad. Kafka-backup fue eliminado por OOM varias veces ... Parece que -Xmx1024M o Docker memory_limit = 1152M no es suficiente para este clúster :( ¿Alguna idea sobre cómo calcular el tamaño de HEAP / RAM para kafka-backup?

Lo siento, se perdió la actualización. Siéntase libre de agregar otro comentario;)

No tengo idea de cómo calcular eso en este momento. Han abierto un nuevo boleto # 47 para esa discusión.

¿Quieres que depure un poco estos datos? No puedo subirlo porque contiene datos confidenciales de la empresa ...

¡Sí, por favor! ¡Que sería increíble!

itadventurer en 31 mar. 2020

¿Quieres que depure un poco estos datos? No puedo subirlo porque contiene datos confidenciales de la empresa ...
¡Sí, por favor! ¡Que sería increíble!

Desafortunadamente, no soy experto en depuración de Java ... aunque puedo ejecutar algo si me guias en esto.

jay7x en 31 mar. 2020

Ok, intentaré pensar cómo hacerlo durante los próximos días, tal vez yo mismo encuentre el problema por casualidad: alegría: (quiero escribir más pruebas)
¡Tal vez si fuera posible reproducir eso con datos que no sean de la empresa, sería increíble!

itadventurer en 31 mar. 2020

De acuerdo con lo que vi aquí, le sugiero que elimine el proceso de copia de seguridad de kafka kill -9 varias veces. Supongo que puede llegar al estado :) Realmente espero que no esté relacionado con eCryptfs ...

jay7x en 31 mar. 2020

También lo he visto hoy en mi configuración de prueba ... Actualmente no puedo reproducirlo. Lo intentaré de nuevo durante los próximos días…

itadventurer en 2 abr. 2020

👍1

Vuelve a entrar en esto después de unas horas de # 88 y un OOM ..

jay7x en 30 may. 2020

Vi esto esta noche en el cierre del servicio kafka-backup antes de hacer la copia de seguridad de Azure Blobstore:

May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,572] INFO WorkerSinkTask{id=chrono_prod-backup-sink-0} Committing offsets synchronously using sequence number 2782: {xxx-4=OffsetAndMetadata{offset=911115, leaderEpoch=null, metadata=''}, yyy-5=OffsetAndMetadata{offset=11850053, leaderEpoch=null, metadata=''}, [...]
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,622] ERROR WorkerSinkTask{id=chrono_prod-backup-sink-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask:179)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: org.apache.kafka.common.errors.WakeupException
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.maybeTriggerWakeup(ConsumerNetworkClient.java:511)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:275)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:233)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:212)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsSync(ConsumerCoordinator.java:937)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1473)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1431)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommitSync(WorkerSinkTask.java:333)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommit(WorkerSinkTask.java:361)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:432)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.closePartitions(WorkerSinkTask.java:591)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:196)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:177)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:227)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.lang.Thread.run(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,634] ERROR WorkerSinkTask{id=chrono_prod-backup-sink-0} Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:180)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,733] INFO Stopped BackupSinkTask (de.azapps.kafkabackup.sink.BackupSinkTask:139)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,771] INFO [Consumer clientId=connector-consumer-chrono_prod-backup-sink-0, groupId=connect-chrono_prod-backup-sink] Revoke previously assigned partitions [...]

jay7x en 31 may. 2020

: pensando: tal vez debería intentar reproducirlo dejando ejecutar Kafka Backup durante unas horas y producir una gran cantidad de datos ... necesito pensar en cómo depurar eso de la manera más significativa ...

Creo que ayudaría un poco si pudieras monitorear la configuración de Kafka Backup. Quizás veamos algo útil en las métricas: pensar:

itadventurer en 1 jun. 2020

Reproduzco el mismo error:

[2020-07-10 11:05:21,755] ERROR WorkerSinkTask{id=backup-sink-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask)
java.lang.NullPointerException
    at de.azapps.kafkabackup.sink.BackupSinkTask.close(BackupSinkTask.java:122)
    at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:397)
    at org.apache.kafka.connect.runtime.WorkerSinkTask.closePartitions(WorkerSinkTask.java:591)
    at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:196)
    at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:177)
    at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:227)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

Estoy usando una configuración de pod en k8s y un sistema de archivos Azure File Share para almacenar la copia de seguridad. Intentaré agregar algunos registros en este punto.

andresgomezfrr en 10 jul. 2020

¿Fue útil esta página

0 / 5 - 0 calificaciones

Temas relacionados

bucle "el tiempo de espera de la encuesta del consumidor ha expirado" (era "kafka-backup puede fallar debido a una E / S del disco lenta")

jay7x · 18Comentarios

No se pudo deserializar el valor para el encabezado 'kafka_replyPartition' en el tema

jay7x · 15Comentarios

¿Cómo se pueden hacer copias de seguridad de todos los temas usando expresiones regulares?

huyngopt1994 · 5Comentarios

Admite copias de seguridad puntuales

akamensky · 13Comentarios

Proporcione ejemplos para diferentes configuraciones.

itadventurer · 5Comentarios