Kafka-backup: Еще один NPE

JFYI, я стер его и начал с новой резервной копии. Не стесняйтесь закрывать этот выпуск.

Хм ... Это странно ... Вот соответствующие строки кода: https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup # L121 -L122

partitionWriters заполняются при вызове open() в https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azappsup/kafkfk BackupSinkTask.java # L107
Это вызывается при каждом открытии TopicPartition ... Мне не понятно, почему это происходит :(

Есть ли у вас ваши данные для дальнейшей отладки? Было бы интересно попробовать воспроизвести. Мы должны хотя бы показать значимую ошибку вместо того, чтобы просто бросать NPE ...

Привет! Да, у меня все еще есть резервная копия старого каталога. Хотя его использование может повлиять на текущее состояние резервного копирования кластера, я думаю, поскольку я не менял имя приемника ..

Я предполагаю, что этот целевой каталог был каким-то образом сломан во время попыток включения eCryptfs. Возможно, какой-то файл был изменен случайно или что-то в этом роде.

Хм… Он содержит секретную информацию? Если нет, загрузите его на https://send.firefox.com/ и отправьте мне ссылку. Попробую воспроизвести ошибку.
В противном случае вы можете попытаться воспроизвести его с новым кластером, или мы пока закрываем проблему, надеясь, что вы правы;)

Произошло сегодня и на другом кластере ...
У меня есть задание cron для резервного копирования Azure, которое останавливает kafka-backup, затем размонтирует eCryptfs, затем выполняет azcopy sync , затем снова монтирует eCryptfs и запускает kafka-backup.
Сегодняшний шаг umount завершился неудачно, значит, скрипт тоже не прошел ( set -e ). Я думаю, это время, когда возникает проблема. Хотя мне нужно внимательно перепроверить сроки. Обновим эту проблему позже.

UPD. Я только что проверил логи. NPE на самом деле произошло раньше. Kafka-backup был убит OOM несколько раз ... Кажется, -Xmx1024M или Docker memory_limit=1152M недостаточно для этого кластера :( Любые идеи о том, как рассчитать размер HEAP / RAM для kafka-backup ?

Вы хотите, чтобы я немного отладил эти данные? Я не могу загрузить его, так как он содержит конфиденциальные данные компании ...

Кстати, может сбой приемника вызвать выход из кафки-подключения? Было бы неплохо, если бы весь автономный процесс подключения завершился ошибкой в ​​случае отказа одного приемника (когда другого приемника / соединителя не существует).

Кстати, может сбой приемника вызвать выход из кафки-подключения? Было бы неплохо, если бы весь автономный процесс подключения завершился ошибкой в ​​случае отказа одного приемника (когда другого приемника / соединителя не существует).
См. №46

UPD. Я только что проверил логи. NPE на самом деле произошло раньше. Kafka-backup был убит OOM несколько раз ... Кажется, -Xmx1024M или Docker memory_limit = 1152M недостаточно для этого кластера :( Есть идеи о том, как рассчитать размер HEAP / RAM для kafka-backup?

Извините, я пропустил обновление. Не стесняйтесь просто добавить еще один комментарий;)

Я не знаю, как это вычислить прямо сейчас. Открыли новый билет № 47 для этого обсуждения.

Вы хотите, чтобы я немного отладил эти данные? Я не могу загрузить его, так как он содержит конфиденциальные данные компании ...

Да, пожалуйста! Это было бы круто!

Вы хотите, чтобы я немного отладил эти данные? Я не могу загрузить его, так как он содержит конфиденциальные данные компании ...

Да, пожалуйста! Это было бы круто!

К сожалению, я не умею отлаживать java ... хотя я могу кое-что запустить, если вы мне поможете.

Хорошо, я постараюсь подумать, как это сделать, в ближайшие дни, может быть, сам найду проблему случайно: joy: (хочу написать больше тестов)
Может быть, если это удастся воспроизвести с данными, не принадлежащими компании, это было бы здорово!

Согласно тому, что я здесь увидел, я бы посоветовал вам несколько раз убить процесс kafka-backup с помощью kill -9 . Думаю, вы можете добраться до состояния :) Очень надеюсь, что это не связано с eCryptfs ...

Я видел это сегодня и в своей тестовой установке… В настоящее время мне не удается воспроизвести его. Попробую еще раз в ближайшие дни…

Попробуй еще раз после нескольких часов # 88 и одного OOM ..

Видел это сегодня вечером при завершении работы службы kafka-backup перед выполнением резервного копирования хранилища BLOB-объектов Azure:

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

: think: может мне стоит попытаться воспроизвести это, позволив запустить Kafka Backup на несколько часов и сгенерировав много данных ... нужно подумать о том, как отладить это наиболее значимым образом ...

Я думаю, что это немного поможет, если вы сможете контролировать настройку Kafka Backup. Может быть, мы увидим что-нибудь полезное в метриках: Think:

Повторяю ту же ошибку:

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

Я использую pod setup en k8s и файловую систему Azure File Share для хранения резервной копии. На этом этапе я постараюсь добавить несколько логов.