Kafka-backup: Encore un NPE

Créé le 17 mars 2020 · 16Commentaires · Source: itadventurer/kafka-backup

Il suffit d'accéder à NPE ci-dessous hier (en utilisant le commit 3c95089c). Essayé aujourd'hui avec le dernier commit du maître (f30b9ad9) bien qu'il soit toujours là. La sortie ci-dessous provient de la dernière version.

Qu'est-ce qui a changé. J'ai fait la migration vers eCryptfs. J'ai arrêté kafka-backup, renommé le répertoire cible, vidé et chattr +i la configuration du récepteur de sauvegarde (pour empêcher le redémarrage de kafka-backup par Puppet). Ensuite, j'ai déployé les modifications eCryptfs, rsync en arrière, puis annulé chattr +i et réappliqué Puppet.

Maintenant, la question principale devrions-nous essayer de déboguer cela? Ou dois-je simplement l'effacer et faire une nouvelle sauvegarde ? C'est QA donc nous avons un peu de temps au cas où.

[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

Source

jay7x

Tous les 16 commentaires

JFYI, je l'ai effacé et j'ai commencé avec une nouvelle sauvegarde. N'hésitez pas à clore ce sujet.

jay7x le 20 mars 2020

Hmm… C'est bizarre… Les lignes de code pertinentes sont celles-ci ici : https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink/BackupSinkvaT #L121 -L122

partitionWriters sont remplis sur l'appel open() dans https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink/ BackupSinkTask.java#L107
Qui est appelé pour chaque TopicPartition à ouvrir… Cela n'a pas de sens pour moi pourquoi cela se produit :(

Vos données sont-elles toujours disponibles pour un débogage ultérieur ? Ce serait intéressant d'essayer de reproduire. Nous devrions au moins montrer une erreur significative au lieu de simplement lancer un NPE…

itadventurer le 21 mars 2020

Salut! Oui, j'ai toujours une ancienne sauvegarde de répertoire. Bien que son utilisation puisse affecter l'état actuel de la sauvegarde du cluster, je suppose que je n'ai pas changé le nom du récepteur.

jay7x le 23 mars 2020

Je suppose que ce répertoire cible a été cassé d'une manière ou d'une autre lors des tentatives d'activation d'eCryptfs. Peut-être qu'un fichier a été modifié accidentellement ou quelque chose comme ça.

jay7x le 23 mars 2020

Hmm… Contient-il des informations sensibles ? Sinon, n'hésitez pas à le télécharger sur https://send.firefox.com/ et à m'envoyer un lien. J'essaierais de reproduire l'erreur.
Sinon, vous pouvez essayer de le reproduire avec un nouveau cluster ou nous fermons le problème pour l'instant en espérant que vous avez raison ;)

itadventurer le 23 mars 2020

C'est arrivé aujourd'hui sur un autre cluster aussi...
J'ai Azure backup cronjob qui arrête kafka-backup, puis démonte eCryptfs, puis fait azcopy sync , puis remonte eCryptfs et démarre kafka-backup.
Ce soir, l'étape umount échoué, donc le script a également échoué ( set -e ). Je suppose que c'est le moment où le problème se produit. Bien que j'ai besoin de revérifier soigneusement la chronologie. Mettra à jour ce problème plus tard.

UPD. J'ai vérifié les logs tout à l'heure. NPE est arrivé plus tôt en fait. Kafka-backup a été tué plusieurs fois par OOM... Il semble que -Xmx1024M ou Docker memory_limit=1152M ne suffisent pas pour ce cluster :( Des idées sur la façon de calculer la taille HEAP/RAM pour kafka-backup ?

Voulez-vous que je fasse du débogage sur ces données ? Je ne peux pas le télécharger car il contient des données sensibles de l'entreprise...

jay7x le 24 mars 2020

👍1

BTW peut-il échouer à cause de la sortie de kafka-connect ? Ce serait bien si tout le processus de connexion autonome échoue en cas de défaillance d'un seul récepteur (lorsqu'aucun autre récepteur/connecteur n'existe).

jay7x le 27 mars 2020

BTW peut-il échouer à cause de la sortie de kafka-connect ? Ce serait bien si tout le processus de connexion autonome échoue en cas de défaillance d'un seul récepteur (lorsqu'aucun autre récepteur/connecteur n'existe).
Voir #46

UPD. J'ai vérifié les logs tout à l'heure. NPE est arrivé plus tôt en fait. Kafka-backup a été tué plusieurs fois par OOM... Il semble que -Xmx1024M ou Docker memory_limit=1152M ne soit pas suffisant pour ce cluster :( Avez-vous des idées sur la façon de calculer la taille HEAP/RAM pour kafka-backup ?

Désolé d'avoir raté la mise à jour. N'hésitez pas à ajouter un autre commentaire ;)

Je n'ai aucune idée de comment calculer cela pour le moment. Avoir ouvert un nouveau ticket #47 pour cette discussion

Voulez-vous que je fasse du débogage sur ces données ? Je ne peux pas le télécharger car il contient des données sensibles de l'entreprise...

Oui s'il vous plaît! Ce serait génial!

itadventurer le 31 mars 2020

Voulez-vous que je fasse du débogage sur ces données ? Je ne peux pas le télécharger car il contient des données sensibles de l'entreprise...
Oui s'il vous plaît! Ce serait génial!

Je ne suis malheureusement pas compétent en débogage Java... bien que je puisse exécuter quelque chose si vous me guidez à ce sujet.

jay7x le 31 mars 2020

Ok, je vais essayer de réfléchir à comment faire ça dans les prochains jours peut-être que je trouve le problème moi-même par hasard :joy: (je veux écrire plus de tests)
Peut-être que s'il est possible de reproduire cela avec des données non-entreprise, ce serait génial !

itadventurer le 31 mars 2020

D'après ce que j'ai vu ici, je vous suggère de tuer le processus de sauvegarde de kafka de kill -9 quelques fois. Je suppose que vous pouvez arriver à l'état :) J'espère vraiment que ce n'est pas lié à eCryptfs...

jay7x le 31 mars 2020

Je l'ai vu aujourd'hui dans ma configuration de test aussi… Actuellement, je ne parviens pas à le reproduire. A réessayer dans les prochains jours…

itadventurer le 2 avr. 2020

👍1

Frappez-le à nouveau après quelques heures de #88 et un OOM ..

jay7x le 30 mai 2020

Vu ce soir sur l'arrêt du service kafka-backup avant de faire la sauvegarde 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 le 31 mai 2020

:pensant: peut-être que je devrais essayer de le reproduire en laissant exécuter Kafka Backup pendant quelques heures et en produisant beaucoup de données… je dois réfléchir à la façon de déboguer cela de la manière la plus significative…

Je pense que cela aiderait un peu si vous pouviez surveiller votre configuration Kafka Backup. Peut-être verrons-nous quelque chose d'utile dans les métriques :thinking:

itadventurer le 1 juin 2020

Je reproduis la même erreur :

[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)

J'utilise une configuration de pod en k8s et le système de fichiers Azure File Share pour stocker la sauvegarde. Je vais essayer d'ajouter des journaux à ce stade.

andresgomezfrr le 10 juil. 2020

Cette page vous a été utile?

0 / 5 - 0 notes

Questions connexes

Compensation du consommateur

ipochi · 3Commentaires

Fournir des exemples pour différentes configurations

itadventurer · 5Commentaires

Échec de la désérialisation de la valeur de l'en-tête « kafka_replyPartition » sur le sujet

jay7x · 15Commentaires

Prise en charge des sauvegardes ponctuelles

akamensky · 13Commentaires

boucle « le délai d'attente de l'interrogation du consommateur a expiré » (était « la sauvegarde de Kafka peut échouer en raison d'E/S de disque lentes »)

jay7x · 18Commentaires