डेटा इंजीनियरिंग इंटरव्यू: Kafka 4.2 ZooKeeper-से-KRaft माइग्रेशन के लिए अपग्रेड गेट्स

प्रॉम्प्ट और संदर्भ

एक मल्टी-टेनेंट Kafka क्लस्टर अभी भी ZooKeeper चलाता है। टीम KRaft में माइग्रेट करना चाहती है और Kafka 4.2 में अपग्रेड करना चाहती है। क्लस्टर ट्रांजैक्शनल प्रोड्यूसर्स, Kafka Streams, और Connect का उपयोग करता है, और संदेश हानि, डुप्लिकेट कमिट या लंबे आउटेज को बर्दाश्त नहीं कर सकता है। प्रीफ्लाइट चेक्स, रोलिंग अपग्रेड, metadata-version गेट्स, क्लाइंट अनुकूलता, विफलता रिकवरी, और रोलबैक डिज़ाइन करें।

इंटरव्यूअर क्या जांचता है

• यह पहचानना कि Kafka 4.2 सामान्य ब्रोकर प्रतिस्थापन के बजाय केवल KRaft (KRaft-only) पर काम करता है।
• सॉफ़्टवेयर संस्करण, metadata.version, और माइग्रेशन स्थिति को अलग करना।
• 4.2.0 के Streams ऑफ़लाइन-माइग्रेशन और ट्रांजैक्शनल-प्रोड्यूसर अपग्रेड फिक्स को ध्यान में रखते हुए 4.2.1 को चुनना।
• सत्यापन में कंट्रोलर्स, ब्रोकर्स, क्लाइंट्स, Connect, और Streams को शामिल करना।
• यह जानना कि रोलबैक कब समर्थित है और कब मेटाडेटा परिवर्तनों के लिए फ़ॉरवर्ड रिकवरी की आवश्यकता होती है।

स्पष्ट करने योग्य प्रश्न

1. Kafka, ZooKeeper, क्लाइंट, और Streams के संस्करण क्या हैं, और क्या वे KRaft माइग्रेशन की पूर्व-आवश्यकताओं को पूरा करते हैं?
2. ट्रांजैक्शनल आइडम्पोटेंस, ट्रांजैक्शन टाइमआउट्स, और ओपन ट्रांजैक्शन्स को कैसे देखा जाता है?
3. क्या क्रॉस-रीजन रेप्लिकेशन, MirrorMaker, या एक सत्यापित रिकवरी क्लस्टर मौजूद है?
4. क्या वर्कलोड्स Streams Rebalance Protocol, Share Groups, या अन्य 4.2 सुविधाओं का उपयोग करते हैं?
5. व्यवसाय किस रोलिंग विंडो, कंज्यूमर रीबैलेंस, और रोलबैक समय को स्वीकार कर सकता है?

30-सेकंड का उत्तर

मैं 4.2 को एक आर्किटेक्चर माइग्रेशन के रूप में मानूँगा: एक ZooKeeper क्लस्टर को अपग्रेड करने से पहले KRaft में माइग्रेट करना होगा। मैं 4.2.0 के Streams ऑफ़लाइन-माइग्रेशन दोष और ट्रांजैक्शनल-प्रोड्यूसर रोलिंग-अपग्रेड समस्या से बचने के लिए 4.2.1 को लक्षित करूँगा। माइग्रेशन से पहले, उच्च-जोखिम वाले परिवर्तनों को रोकें और क्लाइंट्स, ट्रांजैक्शन्स, Streams स्थिति, और रिकवरी रेप्लिकास की सूची बनाएं। सॉफ़्टवेयर को पहले रोल करें, व्यवहार और प्रदर्शन का निरीक्षण करें, और metadata.version को अलग से बढ़ाएं। प्रत्येक चरण एंड-टू-एंड संदेशों, ट्रांजैक्शन कमिट्स, कंज्यूमर लैग, कंट्रोलर कोरम, और Streams स्थिति की जाँच करता है। यदि कोई चरण विफल हो जाता है, तो मेटाडेटा एक्टिवेशन से पहले रुकें या मेटाडेटा परिवर्तनों को एक प्रतिवर्ती स्विच के रूप में मानने के बजाय एक समर्थित संगत पथ के माध्यम से रिकवर करें।

चरण-दर-चरण गहन विश्लेषण

1. संस्करण और स्थिति मैट्रिक्स बनाएं

Kafka 4.2 केवल KRaft का समर्थन करता है, इसलिए ZooKeeper मोड को पहले माइग्रेट किया जाना चाहिए। सॉफ़्टवेयर संस्करण, मेटाडेटा संस्करण, और कंट्रोलर कोरम स्थिति स्वतंत्र आयाम हैं। पूर्व-आवश्यकताओं की पुष्टि करें और एक ऑडिट योग्य चेकलिस्ट में ब्रोकर, कंट्रोलर, क्लाइंट, Connect, Streams, और प्रोटोकॉल संस्करणों को रिकॉर्ड करें।

ZooKeeper -> KRaft migration -> rolling broker/controller upgrade -> verify -> raise metadata.version
    |             |                      |                         |
    +-- blocked --+----------------------+----------> stop and recover

2. निश्चित संस्करण और क्रम चुनें

4.2.1 को लक्ष्य के रूप में उपयोग करें। आधिकारिक अपग्रेड गाइड में ट्रांजैक्शनल-प्रोड्यूसर रोलिंग अपग्रेड के लिए एक फिक्स शामिल है जो UnsupportedVersionException उत्पन्न कर सकता था और Streams Rebalance Protocol ऑफ़लाइन माइग्रेशन दोष के लिए एक फिक्स शामिल है; 4.2.0 को प्रभावित classic-से-streams-group माइग्रेशन को नहीं चलाना चाहिए। पहले टूलिंग और क्लाइंट मैट्रिक्स को अपग्रेड करें, फिर कई विफलता डोमेन को एक साथ बदलने से बचने के लिए एक समय में एक ब्रोकर को रोल करें।

3. मेटाडेटा और कंट्रोलर परिवर्तनों के लिए गेट निर्धारित करें

रोलिंग सॉफ़्टवेयर अपग्रेड के बाद, kafka-features.sh के साथ metadata.version बढ़ाने से पहले क्लस्टर व्यवहार और प्रदर्शन का निरीक्षण करें। गेट्स में कंट्रोलर-कोरम स्थिरता, लीडर चुनाव, मेटाडेटा प्रसार विलंबता (latency), ISR, और डिस्क स्वास्थ्य शामिल हैं। Kafka 4.2 कोई मेटाडेटा परिवर्तन न होने पर डाउनग्रेड समर्थन का दस्तावेजीकरण करता है, लेकिन प्रत्येक लक्षित संस्करण को अपनी मेटाडेटा अनुकूलता जांच की आवश्यकता होती है।

4. ट्रांजैक्शन्स, Streams, और Connect का सत्यापन करें

ट्रांजैक्शन परीक्षण प्रोड्यूसर युगों (epochs), कमिट्स, अबॉर्ट्स, रीस्टार्ट्स, डुप्लिकेट्स, और टाइमआउट्स को कवर करते हैं। Streams परीक्षण स्टेट-स्टोर रेस्टोरेशन, रीबैलेंस, चेंजलॉग्स, प्रोसेसिंग सेमांटिक्स, और ऑफ़लाइन माइग्रेशन पथ को कवर करते हैं। Connect परीक्षण ऑफ़सेट्स, टास्क रीस्टार्ट्स, और बाहरी-सिस्टम आइडम्पोटेंस को कवर करते हैं। प्रत्येक क्लाइंट वर्ग के लिए एंड-टू-एंड प्रोड्यूस/कंज्यूम चेक्स चलाएं; केवल ब्रोकर स्वास्थ्य पर्याप्त नहीं है।

5. विफलताओं का निरीक्षण करें और रिहर्सल करें

कंट्रोलर चुनाव, मेटाडेटा संस्करण, ब्रोकर त्रुटियां, अनुरोध विफलताएं, ट्रांजैक्शन स्थिति, कंज्यूमर लैग, Streams रेस्टोरेशन, Connect टास्क, और डिस्क वृद्धि रिकॉर्ड करें। ब्रोकर रीस्टार्ट, कंट्रोलर हानि, बाधित ट्रांजैक्शन्स, विफल Streams माइग्रेशन, और असंगत क्लाइंट्स का रिहर्सल करें; प्रत्येक परिदृश्य के लिए एक स्टॉप-अपग्रेड और रिकवरी शर्त की आवश्यकता होती है।

6. रोलबैक और रिकवरी सीमाओं को परिभाषित करें

metadata.version बढ़ाने से पहले, पुराने बाइनरीज़, कॉन्फ़िगरेशन, स्नैपशॉट, और एक रिकवरी क्लस्टर रखें, और एक रीड-ओनली सत्यापन विंडो परिभाषित करें। एक रोलिंग-अपग्रेड विफलता एक संगत संस्करण पर रुक सकती है और ब्रोकर्स को पुनर्स्थापित कर सकती है। एक बार जब कोई असमर्थित मेटाडेटा परिवर्तन हो जाता है, तो रोलबैक संगत-स्नैपशॉट रेस्टोरेशन या एक नया क्लस्टर बनाने जैसा हो जाता है; बाइनरी डाउनग्रेड को जबरन लागू न करें। थ्रूपुट बहाल करने से पहले ट्रांजैक्शन और ऑफ़सेट निरंतरता बनाए रखें।

मॉडल उत्तर

मैं पहले यह साबित करूँगा कि यह कोई नियमित संस्करण अपग्रेड नहीं है: Kafka 4.2 ने ZooKeeper समर्थन हटा दिया है, इसलिए मौजूदा क्लस्टर को KRaft में माइग्रेट करना होगा। मैं 4.2.1 का चयन करूँगा क्योंकि आधिकारिक गाइड ट्रांजैक्शनल-प्रोड्यूसर रोलिंग अपग्रेड और Streams ऑफ़लाइन माइग्रेशन के लिए फिक्स का उल्लेख करती है। पहले से, ब्रोकर्स, कंट्रोलर्स, क्लाइंट्स, Connect, Streams, ट्रांजैक्शन्स, और रिकवरी रेप्लिकास को एक संस्करण/स्थिति मैट्रिक्स में सूचीबद्ध करें।

एक समय में एक ब्रोकर को रोल करें, कंट्रोलर कोरम, ISR, विलंबता, और व्यवहार को सत्यापित करें, फिर metadata.version बढ़ाएं। ट्रांजैक्शन परीक्षण युगों, कमिट, अबॉर्ट, रीस्टार्ट, और डुप्लिकेट्स को कवर करते हैं; Streams परीक्षण स्टेट स्टोर्स, चेंजलॉग्स, रीबैलेंस, और माइग्रेशन को कवर करते हैं; Connect परीक्षण ऑफ़सेट्स और टास्क रिकवरी को कवर करते हैं। मेटाडेटा संस्करण, चुनाव, लैग, और त्रुटियों को रिकॉर्ड करें। मेटाडेटा-पूर्व विफलता एक संगत चरण पर रुक सकती है; असमर्थित मेटाडेटा परिवर्तन के बाद, बाइनरी डाउनग्रेड को जबरन लागू करने के बजाय एक स्नैपशॉट या रिकवरी क्लस्टर से पुनर्निर्माण करें।

सामान्य गलतियाँ

• KRaft माइग्रेशन के बिना ZooKeeper ब्रोकर्स को सीधे Kafka 4.2 से बदलना।
• ट्रांजैक्शन्स, Streams स्थिति, Connect ऑफ़सेट्स, और एंड-टू-एंड संदेशों के बजाय केवल ब्रोकर सक्रियता (liveness) की जाँच करना।
• रोलिंग सॉफ़्टवेयर अपग्रेड के तुरंत बाद metadata.version बढ़ाना।
• 4.2.0 पर ज्ञात-जोखिम वाले Streams ऑफ़लाइन माइग्रेशन को चलाना।
• metadata.version को एक साधारण सेटिंग की तरह मानना जिसे हमेशा डाउनग्रेड किया जा सकता है।
• कोई रिकवरी क्लस्टर, स्नैपशॉट, या स्पष्ट स्टॉप-अपग्रेड गेट्स न होना।

फॉलो-अप प्रश्न और उत्तर

ZooKeeper क्लस्टर सीधे Kafka 4.2 में अपग्रेड क्यों नहीं हो सकता?

Kafka 4.2 केवल KRaft का समर्थन करता है और उसने ZooKeeper मोड को हटा दिया है। 4.2 रोलिंग-अपग्रेड पथ में प्रवेश करने से पहले क्लस्टर को माइग्रेट करना होगा और कंट्रोलर कोरम को सत्यापित करना होगा।

metadata.version कब बढ़ाया जाना चाहिए?

सभी ब्रोकर/कंट्रोलर सॉफ़्टवेयर अपग्रेड होने और स्थिर होने के बाद, और कोरम, ISR, क्लाइंट त्रुटियां, और प्रदर्शन पास होने के बाद। इसे अलग से बढ़ाना कोड समस्याओं को प्रोटोकॉल एक्टिवेशन से अलग करता है।

यदि मेटाडेटा एक्टिवेशन के बाद Streams स्टेट रेस्टोरेशन विफल हो जाता है तो क्या होगा?

आगे की सुविधा एक्टिवेशन को रोकें, साक्ष्य और लॉग को सुरक्षित रखें, और एक समर्थित स्नैपशॉट या पुनर्निर्माण पथ से पुनर्प्राप्त करें। चेंजलॉग्स को हटाकर या बाइनरी डाउनग्रेड को जबरन लागू करके विसंगति को न छिपाएं।