Kafka-backup: さらに別のNPE

JFYI、私はそれを一掃し、新しいバックアップから始めました。 この問題はお気軽に終了してください。

うーん…これは奇妙です…関連するコード行は次のとおりです： https ：

partitionWritersは、 https：//github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink/のopen()呼び出しで入力されます。 BackupSinkTask.java＃L107
これは、すべてのTopicPartitionを開くために呼び出されます…なぜこれが発生するのか私には意味がありません:(

さらなるデバッグのためにデータをまだ利用できますか？ 再現してみると面白いでしょう。 NPEをスローするだけでなく、少なくとも意味のあるエラーを表示する必要があります…

やあ！ はい、まだ古いディレクトリのバックアップがあります。 これを使用すると、現在のクラスターのバックアップ状態に影響する可能性がありますが、シンク名を変更しなかったためだと思います。

ここでの私の推測では、このターゲットディレクトリは、eCryptfsの有効化の試行中に何らかの方法で壊れていました。 たぶん、いくつかのファイルが誤って変更されたか、このようなものです。

うーん…機密情報が含まれていますか？ そうでない場合は、https：//send.firefox.com/にアップロードして、リンクを送ってください。 エラーを再現しようとします。
それ以外の場合は、新しいクラスターで再現するか、問題を解決してください。

今日は別のクラスターでも起こりました...
kafka-backupを停止し、eCryptfsをアンマウントし、 azcopy sync実行し、eCryptfsをマウントして、kafka-backupを開始するAzureバックアップcronジョブがあります。
今夜umountステップが失敗したため、スクリプトも失敗しました（ set -e ）。 問題が発生する時期だと思います。 タイムラインを注意深く再確認する必要がありますが。 この問題は後で更新されます。

UPD。 たった今ログチェックをしました。 NPEは実際には以前に発生しました。 Kafka-backupがOOMによって複数回強制終了されました... -Xmx1024MまたはDocker memory_limit=1152Mは、このクラスターには十分ではないようです：（kafka-backupのHEAP / RAMサイズを計算する方法に関するアイデア？

このデータのデバッグを実行しますか？ 会社の機密データが含まれているため、アップロードできません...

ところで、シンクに失敗するとkafka-connectが終了する可能性がありますか？ シングルシンクに障害が発生した場合（他のシンク/コネクタが存在しない場合）、スタンドアロン接続プロセス全体が失敗すると便利です。

ところで、シンクに失敗するとkafka-connectが終了する可能性がありますか？ シングルシンクに障害が発生した場合（他のシンク/コネクタが存在しない場合）、スタンドアロン接続プロセス全体が失敗すると便利です。
＃46を参照

UPD。 たった今ログチェックをしました。 NPEは実際には以前に発生しました。 Kafka-backupがOOMによって複数回強制終了されました...このクラスターには-Xmx1024MまたはDockermemory_limit = 1152Mでは不十分なようです：（kafka-backupのHEAP / RAMサイズを計算する方法について何かアイデアはありますか？

申し訳ありませんが、更新を逃しました。 コメントを追加してください;）

今のところ、それを計算する方法がわかりません。 その議論のために新しいチケット＃47を開きました

このデータのデバッグを実行しますか？ 会社の機密データが含まれているため、アップロードできません...

はい、お願いします！ それは素晴らしいでしょう！

このデータのデバッグを実行しますか？ 会社の機密データが含まれているため、アップロードできません...

はい、お願いします！ それは素晴らしいでしょう！

残念ながら、私はJavaデバッグに熟練していません...これについて教えていただければ、何かを実行できますが。

わかりました、私は次の日にそれを行う方法を考えようとします多分私は偶然に自分で問題を見つけます：joy :(もっとテストを書きたいです）
たぶん、会社以外のデータでそれを再現することができれば、それは素晴らしいことです！

私がここで見たものによると、kafka-backupプロセスをkill -9数回強制終了することをお勧めします。 私はあなたが状態に達するかもしれないと思います:)私はそれがeCryptfsに関連していないことを本当に望んでいます...

今日もテストセットアップで見ました…現在、再現に失敗しています。 次の日にもう一度試してみます…

＃88と1つのOOMの数時間後にもう一度これにぶつかってください。

Azure blobstoreバックアップを実行する前に、kafka-backupサービスのシャットダウンで今夜これを見ました。

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：Kafka Backupを数時間実行して大量のデータを生成することで再現を試みる必要があるかもしれません…最も意味のある方法でそれをデバッグする方法を考える必要があります…

Kafkaバックアップの設定を監視できれば少し役立つと思います。 たぶん、私たちはメトリクスで何か役に立つものを見るでしょう：thinking：

私は同じエラーを再現します：

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

バックアップを保存するために、ポッドセットアップenk8sとAzureファイル共有ファイルシステムを使用しています。 この時点でいくつかのログを追加しようとします。