Kafka-backup: Lagi-lagi NPE

Dibuat pada 17 Mar 2020 · 16Komentar · Sumber: itadventurer/kafka-backup

Tekan saja NPE di bawah kemarin (menggunakan commit 3c95089c). Mencoba hari ini dengan komit terbaru dari master (f30b9ad9) meskipun masih ada di sini. Output di bawah ini adalah dari versi terbaru.

Apa yang berubah. Saya melakukan migrasi ke eCryptfs. Saya menghentikan kafka-backup, mengganti nama target dir, mengosongkan dan chattr +i 'd backup sink config (untuk mencegah kafka-backup dimulai oleh Wayang lagi). Lalu aku dikerahkan perubahan eCryptfs, lakukan kembali rsync, maka un- chattr +i 'd dan diterapkan kembali Wayang.

Sekarang pertanyaan utama haruskah kita mencoba men-debug ini sama sekali? Atau haruskah saya menghapusnya dan melakukan pencadangan baru lainnya? Ini adalah QA jadi kami punya waktu untuk berjaga-jaga.

[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

Sumber

jay7x

Semua 16 komentar

JFYI, saya menghapusnya dan mulai dengan cadangan baru. Jangan ragu untuk menutup masalah ini.

jay7x pada 20 Mar 2020

Hmm… Ini aneh… Baris kode yang relevan ada di sini: https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink.jaupSinkTask. #L121 -L122

partitionWriters diisi pada panggilan open() di https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/Java/de/azapps/kafkabackup/sink/ BackupSinkTask.java#L107
Yang dipanggil untuk setiap TopicPartition untuk dibuka… Tidak masuk akal bagi saya mengapa ini terjadi :(

Apakah data Anda masih tersedia untuk debugging lebih lanjut? Akan menarik untuk mencoba mereproduksi. Kami setidaknya harus menunjukkan kesalahan yang berarti alih-alih hanya melempar NPE ...

itadventurer pada 21 Mar 2020

Hai! Ya, saya masih memiliki cadangan direktori lama. Meskipun menggunakannya dapat memengaruhi status cadangan cluster saat ini, saya kira karena saya tidak mengubah nama wastafel..

jay7x pada 23 Mar 2020

Dugaan saya di sini adalah direktori target ini rusak dalam beberapa cara selama upaya mengaktifkan eCryptfs. Mungkin beberapa file diubah secara tidak sengaja atau sesuatu seperti ini.

jay7x pada 23 Mar 2020

Hmm… Apakah itu berisi informasi sensitif? Jika tidak, jangan ragu untuk mengunggahnya ke https://send.firefox.com/ dan kirimkan saya tautannya. Saya akan mencoba untuk mereproduksi kesalahan.
Jika tidak, Anda dapat mencoba mereproduksinya dengan cluster baru atau kami menutup masalah untuk saat ini dengan harapan Anda benar;)

itadventurer pada 23 Mar 2020

Terjadi hari ini di cluster lain juga...
Saya memiliki cronjob pencadangan Azure yang menghentikan pencadangan kafka, lalu memasang eCryptfs, lalu melakukan azcopy sync , lalu memasang kembali eCryptfs dan memulai pencadangan kafka.
Malam ini umount langkah gagal, jadi skrip juga gagal ( set -e ). Saya kira ini adalah waktu ketika masalah terjadi. Meskipun saya perlu memeriksa ulang timeline dengan hati-hati. Akan memperbarui masalah ini nanti.

UPD. Saya melakukan pemeriksaan log sekarang. NPE terjadi lebih awal sebenarnya. Cafka-backup dibunuh oleh OOM beberapa kali... Tampaknya -Xmx1024M atau Docker memory_limit=1152M tidak cukup untuk cluster ini :( Ada ide tentang cara menghitung ukuran HEAP/RAM untuk kafka-backup ?

Apakah Anda ingin saya melakukan debugging pada data ini? Saya tidak dapat mengunggahnya karena berisi data sensitif perusahaan...

jay7x pada 24 Mar 2020

👍1

BTW dapatkah sink gagal menyebabkan kafka-connect keluar? Akan lebih baik jika seluruh proses koneksi mandiri akan gagal jika terjadi kegagalan wastafel tunggal (ketika tidak ada wastafel/konektor lain).

jay7x pada 27 Mar 2020

BTW dapatkah sink gagal menyebabkan kafka-connect keluar? Akan lebih baik jika seluruh proses koneksi mandiri akan gagal jika terjadi kegagalan wastafel tunggal (ketika tidak ada wastafel/konektor lain).
Lihat #46

UPD. Saya melakukan pemeriksaan log sekarang. NPE terjadi lebih awal sebenarnya. Cadangan kafka dimatikan oleh OOM beberapa kali... Tampaknya -Xmx1024M atau Docker memory_limit=1152M tidak cukup untuk cluster ini :( Ada ide tentang cara menghitung ukuran HEAP/RAM untuk cadangan kafka?

Maaf ketinggalan update. Jangan ragu untuk menambahkan komentar lain;)

Saya tidak tahu bagaimana menghitungnya sekarang. Telah membuka tiket baru #47 untuk diskusi itu

Apakah Anda ingin saya melakukan debugging pada data ini? Saya tidak dapat mengunggahnya karena berisi data sensitif perusahaan...

Ya silahkan! Itu akan luar biasa!

itadventurer pada 31 Mar 2020

Apakah Anda ingin saya melakukan debugging pada data ini? Saya tidak dapat mengunggahnya karena berisi data sensitif perusahaan...
Ya silahkan! Itu akan luar biasa!

Sayangnya saya tidak ahli dalam debugging java ... meskipun saya dapat menjalankan sesuatu jika Anda membimbing saya dalam hal ini.

jay7x pada 31 Mar 2020

Ok, saya akan mencoba memikirkan bagaimana melakukannya di hari-hari berikutnya mungkin saya menemukan masalah itu sendiri secara kebetulan :joy: (ingin menulis lebih banyak tes)
Mungkin jika memungkinkan untuk mereproduksinya dengan data non-perusahaan, itu akan luar biasa!

itadventurer pada 31 Mar 2020

Menurut apa yang saya lihat di sini, saya menyarankan Anda untuk mematikan proses pencadangan kafka dengan kill -9 beberapa kali. Saya kira Anda dapat mencapai status :) Saya sangat berharap itu tidak terkait dengan eCryptfs ...

jay7x pada 31 Mar 2020

Saya telah melihatnya hari ini dalam pengaturan pengujian saya juga… Saat ini saya gagal untuk mereproduksinya. Akan mencobanya lagi di hari-hari berikutnya…

itadventurer pada 2 Apr 2020

👍1

Pukul ini lagi setelah beberapa jam #88 dan satu OOM..

jay7x pada 30 Mei 2020

Lihat ini malam ini di penutupan layanan pencadangan kafka sebelum melakukan pencadangan 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 pada 31 Mei 2020

:thinking: mungkin saya harus mencoba mereproduksinya dengan membiarkan menjalankan Kafka Backup selama beberapa jam dan menghasilkan banyak data… perlu memikirkan cara men-debug itu dengan cara yang paling berarti…

Saya pikir itu akan sedikit membantu jika Anda dapat memantau pengaturan Cadangan Kafka Anda. Mungkin kita akan melihat sesuatu yang berguna dalam metrik :thinking:

itadventurer pada 1 Jun 2020

Saya mereproduksi kesalahan yang sama:

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

Saya menggunakan pengaturan pod en k8s dan sistem file Berbagi File Azure untuk menyimpan cadangan. Saya akan mencoba menambahkan beberapa log pada saat ini.

andresgomezfrr pada 10 Jul 2020

Apakah halaman ini membantu?

0 / 5 - 0 peringkat

Masalah terkait

Pengimbangan konsumen

ipochi · 3Komentar

Gagal melakukan deserialize nilai untuk header 'kafka_replyPartition' pada topik

jay7x · 15Komentar

Bagaimana cara mencadangkan semua topik menggunakan regex

huyngopt1994 · 5Komentar

Mendukung pencadangan tepat waktu

akamensky · 13Komentar

Berikan contoh untuk konfigurasi yang berbeda

itadventurer · 5Komentar