Kafka-backup: Noch eine NPE

JFYI, ich habe es gelöscht und mit einem neuen Backup angefangen. Gerne können Sie dieses Thema schließen.

Hmm… Das ist seltsam… Die relevanten Codezeilen sind diese hier: https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup .Tsk.javaS #L121 -L122

partitionWriters werden beim open() Aufruf in https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/ink/kafkabackup/s gefüllt
Was für jedes TopicPartition zum Öffnen aufgerufen wird… Es macht für mich keinen Sinn warum das passiert :(

Haben Sie Ihre Daten noch für weitere Fehlersuche zur Verfügung? Wäre interessant zu versuchen zu reproduzieren. Wir sollten zumindest einen sinnvollen Fehler anzeigen, anstatt nur eine NPE zu werfen…

Hi! Ja, ich habe noch eine alte Verzeichnissicherung. Obwohl die Verwendung den aktuellen Cluster-Backup-Status beeinflussen kann, vermute ich, dass ich den Senkennamen nicht geändert habe.

Ich vermute hier, dass dieses Zielverzeichnis während der eCryptfs-Aktivierungsversuche in irgendeiner Weise beschädigt wurde. Vielleicht wurde eine Datei versehentlich geändert oder so.

Hmm… Enthält es sensible Informationen? Wenn nicht, laden Sie es auf https://send.firefox.com/ hoch und senden Sie mir einen Link. Ich würde versuchen den Fehler zu reproduzieren.
Andernfalls könnten Sie versuchen, es mit einem neuen Cluster zu reproduzieren, oder wir schließen das Problem vorerst in der Hoffnung, dass Sie Recht haben ;)

Ist heute auch auf einem anderen Cluster passiert...
Ich habe einen Azure-Backup-Cronjob, der kafka-backup stoppt, dann eCryptfs unmountet, dann azcopy sync ausführt, dann eCryptfs wieder mountet und kafka-backup startet.
Heute Nacht ist der Schritt umount fehlgeschlagen, daher ist auch das Skript fehlgeschlagen ( set -e ). Ich denke, dies ist die Zeit, in der das Problem auftritt. Obwohl ich die Zeitleiste sorgfältig überprüfen muss. Werde dieses Problem später aktualisieren.

UPD. Ich habe gerade die Protokolle überprüft. NPE ist eigentlich früher passiert. Kafka-Backup wurde mehrmals von OOM beendet... Es scheint, dass -Xmx1024M oder Docker memory_limit=1152M für diesen Cluster nicht ausreichen :( Irgendwelche Ideen zur Berechnung der HEAP/RAM-Größe für Kafka-Backup ?

Soll ich diese Daten debuggen? Ich kann es nicht hochladen, da es sensible Daten des Unternehmens enthält...

BTW kann eine fehlgeschlagene Senke dazu führen, dass kafka-connect beendet wird? Es wäre schön, wenn der gesamte eigenständige Verbindungsvorgang bei einem Ausfall einer einzelnen Senke fehlschlägt (wenn keine andere Senke / kein anderer Connector vorhanden ist).

BTW kann eine fehlgeschlagene Senke dazu führen, dass kafka-connect beendet wird? Es wäre schön, wenn der gesamte eigenständige Verbindungsvorgang bei einem Ausfall einer einzelnen Senke fehlschlägt (wenn keine andere Senke / kein anderer Connector vorhanden ist).
Siehe #46

UPD. Ich habe gerade die Protokolle überprüft. NPE ist eigentlich früher passiert. Kafka-Backup wurde mehrmals von OOM beendet ... Es scheint, dass -Xmx1024M oder Docker memory_limit=1152M für diesen Cluster nicht ausreichen :( Irgendwelche Ideen zur Berechnung der HEAP / RAM-Größe für Kafka-Backup?

Sorry habe das Update verpasst. Fühlen Sie sich frei, einfach einen weiteren Kommentar hinzuzufügen ;)

Ich habe gerade keine Ahnung, wie ich das berechnen soll. Habe ein neues Ticket #47 für diese Diskussion eröffnet

Soll ich diese Daten debuggen? Ich kann es nicht hochladen, da es sensible Daten des Unternehmens enthält...

Ja bitte! Das wäre super!

Soll ich diese Daten debuggen? Ich kann es nicht hochladen, da es sensible Daten des Unternehmens enthält...

Ja bitte! Das wäre super!

Ich bin leider nicht in Java-Debugging geübt ... obwohl ich etwas ausführen kann, wenn Sie mich dabei anleiten.

Ok, ich werde mir in den nächsten Tagen überlegen, wie das geht, vielleicht finde ich das Problem selbst zufällig :joy: (will weitere Tests schreiben)
Wenn es möglich wäre, das mit firmenfremden Daten zu reproduzieren, wäre das vielleicht großartig!

Nach dem, was ich hier gesehen habe, würde ich Ihnen vorschlagen, den Kafka-Backup-Prozess um kill -9 einige Male zu beenden. Ich denke, Sie können zum Staat gelangen :) Ich hoffe wirklich, dass es nichts mit eCryptfs zu tun hat ...

Ich habe es heute auch in meinem Testaufbau gesehen… Derzeit kann ich es nicht reproduzieren. Werde es in den nächsten Tagen nochmal probieren…

Schlagen Sie nach ein paar Stunden #88 und einem OOM wieder darauf ein.

Habe dies heute Abend beim Herunterfahren des kafka-backup-Dienstes gesehen, bevor das Azure-Blobstore-Backup durchgeführt wurde:

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 [...]

:thinking: vielleicht sollte ich versuchen, es zu reproduzieren, indem ich Kafka Backup für ein paar Stunden laufen lasse und viele Daten produziere… muss darüber nachdenken, wie man das am sinnvollsten debuggt…

Ich denke, es würde ein wenig helfen, wenn Sie Ihr Kafka Backup-Setup überwachen könnten. Vielleicht sehen wir in den Metriken etwas Nützliches :thinking:

Ich reproduziere den gleichen Fehler:

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

Ich verwende ein Pod-Setup mit k8s und einem Azure File Share-Dateisystem, um die Sicherung zu speichern. Ich werde versuchen, an dieser Stelle einige Protokolle hinzuzufügen.