Kafka-backup: 또 다른 NPE

JFYI, 나는 그것을 지우고 새로운 백업으로 시작했습니다. 이 문제를 닫으십시오.

흠... 이상하네요... 관련 코드 줄은 다음과 같습니다. https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/Backazapps/kafkabackup/sink/java #L121 -L122

partitionWriters 는 https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/sink/java/de/azapps/sinkfkabackup 의 open() 호출에 채워집니다. BackupSinkTask.java#L107
모든 TopicPartition 가 열릴 때마다 호출됩니다... 왜 이런 일이 발생하는지 이해가 되지 않습니다.

추가 디버깅에 사용할 수 있는 데이터가 있습니까? 재현하려고 시도하는 것이 흥미로울 것입니다. NPE를 던지는 대신 최소한 의미 있는 오류를 보여줘야 합니다...

안녕하세요! 예, 여전히 이전 디렉토리 백업이 있습니다. 그것을 사용하면 현재 클러스터 백업 상태에 영향을 미칠 수 있지만 싱크 이름을 변경하지 않았기 때문에 추측합니다.

내 생각에는 이 대상 디렉토리가 eCryptfs를 활성화하는 동안 어떤 식으로든 손상되었습니다. 일부 파일이 실수로 변경되었거나 이와 유사한 것일 수 있습니다.

흠… 민감한 정보가 포함되어 있습니까? https://send.firefox.com/에 업로드하고 링크를 보내주십시오. 나는 오류를 재현하려고 노력할 것입니다.
그렇지 않으면 새로운 클러스터로 재현을 시도하거나 당신이 옳기를 바라면서 문제를 종료합니다 ;)

오늘 다른 클러스터에서도 발생했습니다 ...
kafka-backup을 중지한 다음 eCryptfs를 마운트 해제한 다음 azcopy sync 를 수행한 다음 eCryptfs를 다시 마운트하고 kafka-backup을 시작하는 Azure 백업 cronjob이 있습니다.
오늘 밤 umount 단계가 실패하여 스크립트도 실패했습니다( set -e ). 문제가 발생하는 시점인 것 같습니다. 타임라인을 주의 깊게 다시 확인해야 하지만. 이 문제는 나중에 업데이트됩니다.

UPD. 방금 로그 확인을 했습니다. NPE는 실제로 더 일찍 일어났습니다. Kafka-backup이 OOM에 의해 여러 번 종료되었습니다... -Xmx1024M 또는 Docker memory_limit=1152M 가 이 클러스터에 충분하지 않은 것 같습니다. (kafka-backup의 HEAP/RAM 크기를 계산하는 방법에 대한 아이디어 ?

이 데이터에 대해 디버깅을 하시겠습니까? 회사의 민감한 정보가 포함되어 있어서 올릴 수 없습니다...

BTW가 실패한 싱크로 인해 kafka-connect가 종료될 수 있습니까? 단일 싱크 오류(다른 싱크/커넥터가 없는 경우)의 경우 전체 독립형 연결 프로세스가 실패하면 좋을 것입니다.

BTW가 실패한 싱크로 인해 kafka-connect가 종료될 수 있습니까? 단일 싱크 오류(다른 싱크/커넥터가 없는 경우)의 경우 전체 독립형 연결 프로세스가 실패하면 좋을 것입니다.
#46 참조

UPD. 방금 로그 확인을 했습니다. NPE는 실제로 더 일찍 일어났습니다. Kafka-backup이 OOM에 의해 여러 번 종료되었습니다... -Xmx1024M 또는 Docker memory_limit=1152M이 이 클러스터에 충분하지 않은 것 같습니다. (kafka-backup의 HEAP/RAM 크기를 계산하는 방법에 대한 아이디어가 있습니까?

업데이트를 놓쳐서 죄송합니다. 다른 의견을 자유롭게 추가하십시오 ;)

지금은 어떻게 계산할지 모르겠습니다. 해당 토론에 대한 새 티켓 #47을 열었습니다.

이 데이터에 대해 디버깅을 하시겠습니까? 회사의 민감한 정보가 포함되어 있어서 올릴 수 없습니다...

예, 부탁합니다! 그것은 굉장할 것입니다!

이 데이터에 대해 디버깅을 하시겠습니까? 회사의 민감한 정보가 포함되어 있어서 올릴 수 없습니다...

예, 부탁합니다! 그것은 굉장할 것입니다!

불행히도 나는 자바 디버깅에 능숙하지 않습니다 ... 당신이 이것에 대해 저를 안내하면 무언가를 실행할 수 있습니다.

좋아, 나는 다음 날 동안 어떻게 할 것인지 생각하려고 노력할 것이다. 어쩌면 내가 우연히 문제를 찾을 수도 있다 :joy: (더 많은 테스트를 작성하고 싶다)
회사가 아닌 데이터로 그것을 재현할 수 있다면 정말 대단할 것입니다!

여기에서 본 것에 따르면 kafka-backup 프로세스를 kill -9 몇 번 죽이는 것이 좋습니다. 나는 당신이 상태에 도달 할 수 있다고 생각합니다 :) eCryptfs와 관련이 없기를 정말로 바랍니다 ...

나는 오늘 내 테스트 설정에서도 그것을 보았습니다. 현재 나는 그것을 재현하지 못하고 있습니다. 다음 날에 다시 시도 할 것입니다 ...

#88과 한 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 [...]

:생각: Kafka Backup을 몇 시간 동안 실행하고 많은 데이터를 생성하여 재현해 봐야 할 것 같습니다... 가장 의미 있는 방식으로 디버깅하는 방법에 대해 생각해야 합니다...

Kafka Backup 설정을 모니터링할 수 있다면 조금이나마 도움이 될 것 같습니다. 아마도 지표에서 유용한 것을 볼 수 있을 것입니다.

동일한 오류를 재현합니다.

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

포드 설정 en k8s 및 Azure 파일 공유 파일 시스템을 사용하여 백업을 저장하고 있습니다. 이 시점에서 몇 가지 로그를 추가하려고 합니다.