Kafka-backup: एक और एनपीई

को निर्मित 17 मार्च 2020 · 16टिप्पणियाँ · स्रोत: itadventurer/kafka-backup

कल से नीचे एनपीई में हिट करें (3c95089c प्रतिबद्ध का उपयोग करके)। मास्टर (f30b9ad9) से नवीनतम प्रतिबद्धता के साथ आज कोशिश की, हालांकि यह अभी भी यहां है। नीचे आउटपुट नवीनतम संस्करण से है।

क्या बदला है। मैंने eCryptfs में माइग्रेशन किया। मैंने काफ्का-बैकअप को रोक दिया, लक्ष्य डीआईआर का नाम बदला, खाली किया और chattr +i 'डी बैकअप सिंक कॉन्फिगरेशन (काफ्का-बैकअप को कठपुतली द्वारा फिर से शुरू करने से रोकने के लिए)। फिर मैंने eCryptfs परिवर्तनों को तैनात किया, rsync वापस किया, फिर un- chattr +i 'd इसे किया और कठपुतली को फिर से लागू किया।

अब मुख्य प्रश्न क्या हमें इसे डिबग करने का प्रयास करना चाहिए? या क्या मुझे इसे मिटा देना चाहिए और एक और ताजा बैकअप करना चाहिए? यह क्यूए है इसलिए हमारे पास मामले में कुछ समय है।

[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

स्रोत

jay7x

सभी 16 टिप्पणियाँ

जेएफवाईआई, मैंने इसे मिटा दिया और ताजा बैकअप के साथ शुरुआत की। इस मुद्दे को बंद करने के लिए स्वतंत्र महसूस करें।

jay7x 20 मार्च 2020

हम्म… यह अजीब है… कोड की प्रासंगिक पंक्तियाँ ये हैं: https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink.BackupSink #L121 -L122

partitionWriters https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink/ में open() कॉल पर भरे जाते हैं। बैकअप सिंक टास्क.जावा#L107
जिसे खोलने के लिए प्रत्येक TopicPartition लिए कहा जाता है ... यह मुझे समझ में नहीं आता कि ऐसा क्यों होता है :(

क्या आपके पास आगे डिबगिंग के लिए आपका डेटा अभी भी उपलब्ध है? पुनरुत्पादन की कोशिश करना दिलचस्प होगा। हमें केवल एनपीई फेंकने के बजाय कम से कम एक सार्थक त्रुटि दिखानी चाहिए…

itadventurer 21 मार्च 2020

नमस्ते! हां, मेरे पास अभी भी पुरानी निर्देशिका बैकअप है। हालांकि इसका उपयोग करने से वर्तमान क्लस्टर बैकअप स्थिति प्रभावित हो सकती है, मुझे लगता है कि मैंने सिंक नाम नहीं बदला है।

jay7x 23 मार्च 2020

मेरा अनुमान है कि यह लक्ष्य dir किसी तरह से eCryptfs को सक्षम करने के प्रयासों के दौरान तोड़ा गया था। हो सकता है कि कोई फ़ाइल गलती से बदल गई हो या ऐसा कुछ।

jay7x 23 मार्च 2020

हम्म... क्या इसमें संवेदनशील जानकारी है? अगर बेझिझक इसे https://send.firefox.com/ पर अपलोड करें और मुझे एक लिंक भेजें। मैं त्रुटि को पुन: उत्पन्न करने का प्रयास करूंगा।
अन्यथा, आप इसे एक नए क्लस्टर के साथ पुन: पेश करने का प्रयास कर सकते हैं या हम इस उम्मीद के लिए इस मुद्दे को बंद कर देते हैं कि आप सही हैं;)

itadventurer 23 मार्च 2020

आज एक और क्लस्टर पर भी हुआ...
मेरे पास Azure बैकअप क्रोनजॉब है जो काफ्का-बैकअप को रोक रहा है, फिर eCryptfs को umounting कर रहा है, फिर azcopy sync , फिर eCryptfs को वापस माउंट कर रहा है और काफ्का-बैकअप शुरू कर रहा है।
आज रात umount चरण विफल रहा, इसलिए स्क्रिप्ट भी विफल रही ( set -e )। मुझे लगता है कि यह वह समय है जब समस्या होती है। हालांकि मुझे समयरेखा को ध्यान से दोबारा जांचना होगा। इस मुद्दे को बाद में अपडेट करेंगे।

यूपीडी. मैंने अभी लॉग चेक किया था। एनपीई वास्तव में पहले हुआ था। काफ्का-बैकअप ओओएम द्वारा कई बार मारा गया था ... ऐसा लगता है कि -Xmx1024M या डॉकर memory_limit=1152M इस क्लस्टर के लिए पर्याप्त नहीं है :( काफ्का-बैकअप के लिए HEAP/RAM आकार की गणना करने के तरीके के बारे में कोई विचार ?

क्या आप चाहते हैं कि मैं इस डेटा पर कुछ डिबगिंग करूँ? मैं इसे अपलोड नहीं कर सकता क्योंकि इसमें कंपनी का संवेदनशील डेटा है...

jay7x 24 मार्च 2020

👍1

BTW विफल सिंक काफ्का-कनेक्ट से बाहर निकलने का कारण बन सकता है? यह अच्छा होगा यदि एकल सिंक विफलता (जब कोई अन्य सिंक/कनेक्टर मौजूद नहीं है) के मामले में पूरी स्टैंडअलोन कनेक्ट प्रक्रिया विफल हो जाएगी।

jay7x 27 मार्च 2020

BTW विफल सिंक काफ्का-कनेक्ट से बाहर निकलने का कारण बन सकता है? यह अच्छा होगा यदि एकल सिंक विफलता (जब कोई अन्य सिंक/कनेक्टर मौजूद नहीं है) के मामले में पूरी स्टैंडअलोन कनेक्ट प्रक्रिया विफल हो जाएगी।
#46 . देखें

यूपीडी. मैंने अभी लॉग चेक किया था। एनपीई वास्तव में पहले हुआ था। काफ्का-बैकअप OOM द्वारा कई बार मारा गया था... ऐसा लगता है -Xmx1024M या Docker memory_limit=1152M इस क्लस्टर के लिए पर्याप्त नहीं है :( काफ्का-बैकअप के लिए HEAP/RAM आकार की गणना करने के तरीके के बारे में कोई विचार?

क्षमा करें अद्यतन याद किया। बस एक और टिप्पणी जोड़ने के लिए स्वतंत्र महसूस करें;)

मुझे नहीं पता कि अभी इसकी गणना कैसे की जाए। उस चर्चा के लिए एक नया टिकट #47 खोला है

क्या आप चाहते हैं कि मैं इस डेटा पर कुछ डिबगिंग करूँ? मैं इसे अपलोड नहीं कर सकता क्योंकि इसमें कंपनी का संवेदनशील डेटा है...

जी बोलिये! वह तो जबर्दस्त होगा!

itadventurer 31 मार्च 2020

क्या आप चाहते हैं कि मैं इस डेटा पर कुछ डिबगिंग करूँ? मैं इसे अपलोड नहीं कर सकता क्योंकि इसमें कंपनी का संवेदनशील डेटा है...
जी बोलिये! वह तो जबर्दस्त होगा!

मैं दुर्भाग्य से जावा डिबगिंग में कुशल नहीं हूं ... हालांकि अगर आप मुझे इस पर मार्गदर्शन करते हैं तो मैं कुछ चला सकता हूं।

jay7x 31 मार्च 2020

ठीक है, मैं यह सोचने की कोशिश करूंगा कि अगले दिनों के दौरान मैं इसे कैसे कर सकता हूं, शायद मुझे इस मुद्दे को संयोग से मिल जाए: खुशी: (अधिक परीक्षण लिखना चाहते हैं)
हो सकता है कि अगर गैर-कंपनी डेटा के साथ इसे पुन: पेश करना संभव हो तो यह बहुत बढ़िया होगा!

itadventurer 31 मार्च 2020

मैंने यहां जो देखा उसके अनुसार, मैं आपको काफ्का-बैकअप प्रक्रिया को kill -9 कुछ बार मारने का सुझाव दूंगा। मुझे लगता है कि आप राज्य में पहुंच सकते हैं :) मुझे वाकई उम्मीद है कि यह ई-क्रिप्टफ्स से संबंधित नहीं है ...

jay7x 31 मार्च 2020

मैंने इसे आज अपने परीक्षण सेटअप में भी देखा है... वर्तमान में मैं इसे पुन: पेश करने में विफल हो रहा हूं। अगले दिनों में फिर से कोशिश करेंगे…

itadventurer 2 अप्रैल 2020

👍1

#88 और एक OOM के कुछ घंटों के बाद फिर से इसमें शामिल हों।

jay7x 30 मई 2020

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 31 मई 2020

: सोच: शायद मुझे कुछ घंटों के लिए काफ्का बैकअप चलाने और बहुत सारे डेटा का उत्पादन करके इसे पुन: पेश करने का प्रयास करना चाहिए ... इस बारे में सोचने की ज़रूरत है कि इसे सबसे सार्थक तरीके से कैसे डिबग किया जाए ...

मुझे लगता है कि अगर आप अपने काफ्का बैकअप सेटअप की निगरानी कर सकते हैं तो इससे थोड़ी मदद मिलेगी। शायद हम मेट्रिक्स में कुछ उपयोगी देखेंगे: सोच:

itadventurer 1 जून 2020

मैं एक ही त्रुटि पुन: पेश करता हूं:

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

मैं बैकअप स्टोर करने के लिए पॉड सेटअप एन k8s और Azure फ़ाइल शेयर फाइल सिस्टम का उपयोग कर रहा हूं। मैं इस बिंदु पर कुछ लॉग जोड़ने की कोशिश करूंगा।

andresgomezfrr 10 जुल॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Kafka-backup: एक और एनपीई

सभी 16 टिप्पणियाँ

संबंधित मुद्दों