🏪 😁 💵 कुख्यात कीड़े और ClickHouse के उदाहरण पर उनसे कैसे बचा जाए 👣 🎮 🍵

यदि आप कोड लिख रहे हैं, तो समस्याओं के लिए तैयार रहें। वे निश्चित रूप से होंगे, और उन्हें सभी पक्षों से उम्मीद की जानी चाहिए: आपके कोड और संकलक से, ऑपरेटिंग सिस्टम और हार्डवेयर से, और उपयोगकर्ता कभी-कभी "आश्चर्य" फेंकते हैं। यदि आपने क्लस्टर को कॉस्मिक स्केल पर बढ़ाया है, तो "स्पेस" बग्स की अपेक्षा करें। खासकर जब इंटरनेट ट्रैफिक के डेटा की बात हो।

एलेक्सी मिलोविडोव (o6CuFl2Q) ClickHouse के विकास और समर्थन में अपने अनुभव से सबसे हास्यास्पद, हतोत्साहित और निराशाजनक समस्याओं के बारे में बात करेंगे। आइए देखें कि उन्हें कैसे डिबग किया जाना था और डेवलपर्स को शुरुआत से ही क्या उपाय करना चाहिए, ताकि कम समस्याएं हों।

कुख्यात कीड़े

यदि आपने कुछ कोड लिखा है, तो तुरंत समस्याओं के लिए तैयार हो जाएं।

कोड में त्रुटियां। उनकी आवश्यकता होगी। लेकिन मान लीजिए कि आपने सही कोड लिखा है, संकलित है, लेकिन बग संकलक में दिखाई देंगे और कोड सही ढंग से काम नहीं करेगा। हमने संकलक तय किया, सब कुछ संकलित - इसे चलाएं। लेकिन (अप्रत्याशित रूप से) सब कुछ गलत तरीके से काम करता है, क्योंकि ओएस के कर्नेल में भी कीड़े हैं ।

यदि ओएस में कोई बग नहीं हैं, तो अनिवार्य रूप से, वे हार्डवेयर में होंगे । यहां तक कि अगर आपने सही कोड लिखा है जो पूरी तरह से सही हार्डवेयर पर काम करता है, तो भी आप समस्याओं का सामना करेंगे, उदाहरण के लिए, कॉन्फ़िगरेशन त्रुटियां । ऐसा लगेगा कि आपने सब कुछ सही किया, लेकिन किसी ने कॉन्फ़िगरेशन फ़ाइल में गलती की, और सब कुछ फिर से काम नहीं करता है।

जब सभी बग्स को ठीक कर दिया गया है, तो उपयोगकर्ता इसे समाप्त कर देंगे, क्योंकि वे लगातार आपके कोड "गलत तरीके" का उपयोग करते हैं। लेकिन समस्या निश्चित रूप से उपयोगकर्ताओं में नहीं है, लेकिन कोड में: आपने कुछ ऐसा लिखा है जिसका उपयोग करना मुश्किल है ।

आइए इन बगों को कुछ उदाहरणों के साथ देखें।

विन्यास कीड़े

डेटा का विलोपन । अभ्यास से पहला मामला। सौभाग्य से, मेरा नहीं और यैंडेक्स नहीं, चिंता न करें।

पहले परिचयात्मक। किसी क्लस्टर के मानचित्र-कम आर्किटेक्चर (जैसे कि Hadoop) में कई डेटा सर्वर (डेटा नोड्स) होते हैं जो डेटा स्टोर करते हैं, और एक या अधिक मास्टर सर्वर जो सर्वर पर सभी डेटा का स्थान जानते हैं।

डेटा नोड्स मास्टर का पता जानते हैं और इसे कनेक्ट करते हैं। विज़ार्ड मॉनिटर करता है कि डेटा कहाँ और किस स्थान पर होना चाहिए, और डेटा नोड्स को अलग-अलग कमांड देता है: "डेटा एक्स डाउनलोड करें, आपके पास डेटा वाई होना चाहिए, और डेटा जेड हटाएं"। क्या गलत हो सकता था?

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

सबसे महाकाव्य कीड़े वे हैं जो अनजाने डेटा हटाने का नेतृत्व करते हैं।

इससे बचना बहुत सरल है।

डेटा डिलीट न करें । उदाहरण के लिए, एक अलग निर्देशिका में एक तरफ रख दें या देरी से हटाएं। सबसे पहले, हम स्थानांतरण करते हैं ताकि वे उपयोगकर्ता को दिखाई न दें, और यदि वह पाता है कि कुछ दिनों के भीतर कुछ गायब हो गया है, तो हम वापस लौट आएंगे।

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

यदि कार्यक्रम विनाशकारी क्रियाएं करता है - तो नेटवर्क स्तर पर परीक्षण और उत्पादन को अलग करें(iptables)। उदाहरण के लिए, फाइलें हटाना या ई-मेल भेजना एक विनाशकारी कार्रवाई है क्योंकि यह किसी का ध्यान "खाएगा"। उन पर एक दहलीज रखो: एक सौ पत्र भेजे जा सकते हैं, और एक हजार के लिए एक सुरक्षा चेकबॉक्स डालते हैं, जो कुछ भयानक होने से पहले सेट किया जाता है।

विन्यास । दूसरा उदाहरण मेरे अभ्यास से पहले से है।

एक अच्छी कंपनी में किसी तरह एक अजीब ClickHouse क्लस्टर था। विचित्रता यह थी कि प्रतिकृतियां सिंक्रनाइज़ नहीं हुईं। जब सर्वर को पुनरारंभ किया गया था, तो यह शुरू नहीं हुआ और एक संदेश दिखाई दिया कि सभी डेटा गलत थे: "बहुत सारे अप्रत्याशित डेटा हैं, मैं शुरू नहीं करूंगा। हमें ध्वज सेट करना चाहिए force_restore_dataऔर इसका पता लगाना चाहिए। ”

कंपनी में कोई भी इसका पता नहीं लगा सका - उन्होंने सिर्फ झंडा लगाया। उसी समय, डेटा का आधा भाग कहीं गायब हो गया, जिसके परिणामस्वरूप अंतराल के साथ चार्ट। डेवलपर्स ने मेरी ओर रुख किया, मुझे लगा कि कुछ दिलचस्प हो रहा है, और जांच करने का फैसला किया। जब कुछ घंटे बाद सुबह आई और पक्षी खिड़की से बाहर गाने लगे, तो मुझे महसूस हुआ कि मुझे कुछ समझ नहीं आया।

ClickHouse सर्वर समन्वय के लिए ZooKeeper सेवा का उपयोग करता है। ClickHouse डेटा संग्रहीत करता है, और चिड़ियाघरकीपर निर्धारित करता है कि कौन से सर्वर को किस डेटा पर झूठ बोलना चाहिए: मेटाडेटा को संग्रहीत करता है कि किस डेटा पर प्रतिकृति हो। ज़ूकीपर भी एक क्लस्टर है - यह एक बहुत अच्छा वितरित आम सहमति एल्गोरिथ्म के अनुसार प्रतिकृति करता है, जिसमें सख्त स्थिरता होती है।

एक नियम के रूप में, चिड़ियाघरकीपर 3 मशीनें हैं, कभी-कभी 5. सभी मशीनों को एक साथ ClickHouse कॉन्फ़िगरेशन में सूचीबद्ध किया जाता है, एक कनेक्शन एक यादृच्छिक मशीन के साथ स्थापित किया जाता है, इसके साथ बातचीत करता है, और यह सर्वर सभी अनुरोधों की नकल करता है।

क्या हुआ? कंपनी के पास तीन चिड़ियाघरकीपर सर्वर थे। लेकिन वे तीन नोड्स के क्लस्टर के रूप में काम नहीं करते थे , लेकिन तीन स्वतंत्र नोड्स के रूप में - एक नोड से तीन क्लस्टर। वन क्लिकहाउस एक सर्वर से जुड़ता है और डेटा लिखता है। प्रतिकृतियां इस डेटा को डाउनलोड करना चाहती हैं, लेकिन वे कहीं नहीं मिली हैं। जब पुनरारंभ होता है, तो सर्वर किसी अन्य ज़ूकीपर से जुड़ता है: यह देखता है कि जिस डेटा के साथ उसने पहले काम किया था, वह शानदार है, उसे कहीं स्थगित कर दिया जाना चाहिए। वह उन्हें हटाता नहीं है, लेकिन उन्हें एक अलग निर्देशिका में स्थानांतरित करता है - क्लिकहाउस डेटा में इतनी आसानी से हटाया नहीं जाता है।

मैं चिड़ियाघरकीपर कॉन्फ़िगरेशन को ठीक करने का निर्णय लेता हूं। मैं सभी डेटा का नाम बदला और ATTACHनिर्देशिका से डेटा के कुछ हिस्सों के लिए अनुरोध करता हूं detached/unexpeted_*।

नतीजतन, सभी डेटा को पुनर्स्थापित किया गया था, प्रतिकृतियों को सिंक्रनाइज़ किया गया था, कोई नुकसान नहीं था, ग्राफ़ निरंतर थे। कंपनी संतुष्ट, आभारी है, जैसे कि वे पहले से ही भूल गए थे कि कैसे सब कुछ पहले बुरी तरह से काम किया था।

ये साधारण विन्यास कीड़े थे। अधिक बग कोड में होंगे।

कोड में कीड़े

हम C ++ में कोड लिखते हैं। इसका मतलब है कि हमारे पास पहले से ही समस्याएं हैं।

अगला उदाहरण Yandex.Metrica क्लस्टर (2015) पर उत्पादन से एक वास्तविक बग है - C ++ कोड का परिणाम। बग यह था कि कभी-कभी अनुरोध का जवाब देने के बजाय उपयोगकर्ता को एक त्रुटि संदेश मिला:

"चेकसम मेल नहीं खाता, दूषित डेटा" - चेक राशि मेल नहीं खाती, डेटा टूट गया है - डरावना!
"LRUCache असंगत हो गया। इसमें एक बग होना चाहिए ”- कैश असंगत हो गया, इसमें सबसे अधिक संभावना बग है।

हमने जो कोड लिखा है, वह बताता है कि वहां एक बग है।

" चेकसम मेल नहीं खाता, दूषित डेटा ।" विघटित होने से पहले संपीड़ित डेटा ब्लॉक की जाँच करें। आमतौर पर यह त्रुटि तब दिखाई देती है जब फ़ाइल सिस्टम पर डेटा टूट जाता है। विभिन्न कारणों से, सर्वर के पुनरारंभ होने पर कुछ फाइलें कचरा बन जाती हैं।

लेकिन यहां एक और मामला है: मैंने फ़ाइल को मैन्युअल रूप से पढ़ा, चेक सम मिलान, कोई त्रुटि नहीं है। एक बार दिखाई देने के बाद, बार-बार अनुरोध करने पर त्रुटि पुन: उत्पन्न होती है। जब सर्वर पुनरारंभ होता है, तो थोड़ी देर के लिए त्रुटि गायब हो जाती है, और फिर फिर से दिखाई देता है।

शायद बात रैम में है? एक विशिष्ट स्थिति तब होती है जब बिट्स इसमें पिटाई कर रहे होते हैं। मैं dmesg में देखता हूं(kern.log), लेकिन कोई मशीन जांच अपवाद नहीं है - वे आमतौर पर लिखते हैं जब रैम में कुछ गलत होता है। यदि सर्वर ने रैम को पीटा था, तो न केवल मेरा कार्यक्रम गलत तरीके से काम करेगा, बल्कि अन्य सभी बेतरतीब ढंग से त्रुटियों को उत्पन्न करेंगे। हालाँकि, त्रुटि की कोई अन्य अभिव्यक्तियाँ नहीं हैं।

"LRUCache असंगत हो गया। इसमें एक बग होना चाहिए। ” यह कोड में एक स्पष्ट गलती है, और हम C ++ में लिख रहे हैं - शायद मेमोरी एक्सेस? लेकिन सीआई में कुछ भी नहीं पता AddressSanitizer, ThreadSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer के तहत परीक्षण।

शायद कुछ परीक्षण मामलों को कवर नहीं किया गया है? मैं AddressSanitizer के साथ सर्वर इकट्ठा करता हूं, इसे उत्पादन पर चलाता हूं - यह कुछ भी नहीं पकड़ता है। कुछ समय के लिए, कुछ चिह्न कैश (पाउच कैश) को रीसेट करने से त्रुटि साफ हो जाती है।

प्रोग्रामिंग नियमों में से एक कहता है: यदि यह स्पष्ट नहीं है कि बग क्या है, तो कोड को करीब से देखें, वहां कुछ खोजने की उम्मीद है। मैंने ऐसा किया, एक बग पाया, इसे ठीक किया - यह मदद नहीं करता था। मैं कोड में एक और जगह देखता हूं - एक बग भी है। सही किया, फिर मदद नहीं की। मैंने कुछ और तय किया, कोड बेहतर हो गया, लेकिन त्रुटि अभी भी गायब नहीं हुई!

कारण। सर्वर द्वारा एक पैटर्न खोजने की कोशिश कर रहा है, समय के साथ, लोड की प्रकृति से - कुछ भी मदद नहीं करता है। तब उन्होंने महसूस किया कि समस्या केवल एक समूह पर ही प्रकट होती है, और दूसरों पर कभी नहीं। त्रुटि इतनी बार पुन: प्रस्तुत नहीं की जाती है, लेकिन यह एक पुनरारंभ के बाद हमेशा एक क्लस्टर पर दिखाई देती है, और सब कुछ दूसरे पर साफ होता है।

यह पता चला कि इसका कारण यह है कि "समस्या" क्लस्टर पर उन्होंने एक नई सुविधा - कैश शब्दकोशों का उपयोग किया था। वे हाथ से लिखे मेमोरी एलोकेशन ArenaWithFreeLists का उपयोग करते हैं । हम न केवल सी ++ में लिखते हैं, बल्कि कुछ प्रकार के कस्टम आवंटनकर्ता भी देखते हैं - हम दो बार समस्याओं के लिए खुद को करते हैं।

ArenaWithFreeLists मेमोरी का एक हिस्सा है जिसमें मेमोरी को दो: 16, 32, 64 बाइट्स द्वारा विभाजित आकार में लगातार आवंटित किया जाता है। यदि मेमोरी को मुक्त कर दिया जाता है, तो वे फ्री फ्रीलिस्ट ब्लॉक की एक एकल लिंक की गई सूची बनाते हैं।

कोड को देखते हैं।

class ArenaWithFreeLists
{
    Block * free_lists[16] {};
    static auto sizeToPreviousPowerOfTwo(size_t size)
    {
        return _bit_scan_reverse(size - 1);
    }

    char * alloc(size_t size)
    {
        const auto list_idx = findFreeListIndex(size);
        free_lists[list_idx] ->...
    }
}

यह _bit_scan_reverseशुरुआत में एक अंडरस्कोर के साथ एक फ़ंक्शन का उपयोग करता है ।

एक अलिखित नियम है: "यदि किसी फ़ंक्शन में शुरुआत में एक अंडरस्कोर है, तो उस पर एक बार प्रलेखन पढ़ें, और यदि दो, तो इसे दो बार पढ़ें।"

हम दस्तावेज़ीकरण सुनते हैं और पढ़ते हैं: “int _bit_scan_reverse (int)। 32-बिट पूर्णांक में उच्चतम सेट बिट के सूचकांक में dst सेट करें a। यदि कोई बिट्स निर्धारित नहीं है तो dst अपरिभाषित है । " हमें लगता है कि समस्या मिल गई है।

सी ++ में, इस स्थिति को संकलक के लिए असंभव माना जाता है। कंपाइलर अपरिभाषित व्यवहार का उपयोग कर सकता है, यह "असंभव", कोड के अनुकूलन के लिए एक धारणा के रूप में।

संकलक कुछ भी गलत नहीं करता है - यह ईमानदारी से विधानसभा निर्देश उत्पन्न करता है bsr %edi, %eax। लेकिन, यदि ऑपरेंड शून्य है, तो निर्देश में bsrअपरिभाषित व्यवहार C ++ स्तर पर नहीं, बल्कि CPU स्तर पर होता है। यदि स्रोत रजिस्टर शून्य है, तो गंतव्य रजिस्टर नहीं बदलता है: इनपुट में कुछ कचरा था, यह कचरा आउटपुट पर भी रहेगा।

परिणाम इस बात पर निर्भर करता है कि संकलक इस निर्देश को कहां रखता है। कभी-कभी इस निर्देश के साथ एक फ़ंक्शन इनलाइन होता है, कभी-कभी नहीं। दूसरे मामले में इस कोड की तरह कुछ होगा:

bsrl %edi, %eax
retq

तब मैंने अपने बाइनरी में इसी तरह के कोड का एक उदाहरण देखा objdump।

परिणामों के अनुसार, मैं देखता हूं कि कभी-कभी स्रोत रजिस्टर और गंतव्य रजिस्टर समान होते हैं। यदि शून्य था, तो परिणाम भी शून्य होगा - सब कुछ ठीक है। लेकिन कभी-कभी रजिस्टर अलग होते हैं, और परिणाम कचरा होगा।

यह बग कैसे प्रकट होता है?

हम फ्रीस्टिस्ट सरणी में एक सूचकांक के रूप में कचरा का उपयोग करते हैं। एक सरणी के बजाय, हम कुछ दूर के पते पर जाते हैं और मेमोरी एक्सेस प्राप्त करते हैं।
हम भाग्यशाली हैं, पास के लगभग सभी पते कैश से डेटा से भरे हुए हैं - हम कैश को खराब करते हैं। कैश में फ़ाइल ऑफ़सेट हैं।
हम गलत ऑफसेट पर फाइलें पढ़ते हैं। गलत ऑफसेट से, हमें चेक राशि मिलती है। लेकिन एक चेक-योग नहीं है, लेकिन कुछ और - यह चेक-योग निम्नलिखित डेटा के साथ मेल नहीं खाएगा।
हमें त्रुटि मिलती है "चेकसम मेल नहीं खाता, दूषित डेटा"।

सौभाग्य से, डेटा दूषित नहीं है, लेकिन रैम में केवल कैश है। हमें तुरंत त्रुटि के बारे में सूचित किया गया था, क्योंकि हम डेटा की जांच करते हैं। 27 दिसंबर, 2015 को त्रुटि को ठीक किया गया और जश्न मनाने के लिए चला गया।

जैसा कि आप देख सकते हैं, गलत कोड कम से कम तय किया जा सकता है। लेकिन हार्डवेयर में कीड़े कैसे ठीक करें?

लोहे में कीड़े

ये कीड़े भी नहीं हैं, लेकिन शारीरिक कानून - अपरिहार्य प्रभाव। शारीरिक नियमों के अनुसार, लोहा अनिवार्य रूप से छोटी गाड़ी है।

RAID को गैर-परमाणु लिखें । उदाहरण के लिए, हमने RAID1 बनाया। इसमें दो हार्ड ड्राइव शामिल हैं। इसका मतलब है कि एक सर्वर एक वितरित प्रणाली है: डेटा को एक हार्ड ड्राइव और दूसरे को लिखा जाता है। लेकिन क्या होगा अगर डेटा को एक डिस्क पर लिखा जाए और दूसरे को रिकॉर्ड करते समय पावर खो जाए? RAID1 सरणी पर डेटा सुसंगत नहीं होगा। हम यह नहीं समझ पाएंगे कि कौन सा डेटा सही है, क्योंकि हम एक बाइट या दूसरे को पढ़ेंगे।

आप लॉग को रखकर इससे निपट सकते हैं। उदाहरण के लिए, ZFS में यह समस्या हल हो जाती है, लेकिन बाद में इस पर और अधिक।

HDD और SSD पर थोड़ा सड़ांध। हार्ड ड्राइव और SSDs पर बिट्स वैसे ही खराब हो सकते हैं। आधुनिक SSDs, विशेष रूप से बहु-स्तरीय कोशिकाओं वाले, यह सुनिश्चित करने के लिए डिज़ाइन किए गए हैं कि कोशिकाएं लगातार बिगड़ेंगी। त्रुटि सुधार कोड मदद करते हैं, लेकिन कभी-कभी कोशिकाएं इतनी अधिक और इतनी बिगड़ जाती हैं कि यह भी नहीं बचती है। अनिर्धारित त्रुटियां प्राप्त की जाती हैं।

RAM में थोड़ा फ़्लिप (लेकिन ECC के बारे में क्या?)। सर्वर में RAM में, बिट्स भी दूषित होते हैं। इसमें त्रुटि सुधार कोड भी हैं। जब त्रुटियां होती हैं, तो वे आमतौर पर लिनक्स कर्नेल लॉग में संदेश से दिखाई देते हैं। जब कई त्रुटियां होती हैं, तो हम कुछ ऐसा देखेंगे: "मेमोरी के साथ एन मिलियन त्रुटियां ठीक हो गई हैं।" लेकिन व्यक्तिगत बिट्स पर ध्यान नहीं दिया जाएगा, और निश्चित रूप से कुछ छोटी गाड़ी होगी।

बिट CPU और नेटवर्क स्तर पर फ़्लिप करता है । सीपीयू स्तर पर, सीपीयू कैश में और निश्चित रूप से, नेटवर्क पर डेटा संचारित करते समय त्रुटियां होती हैं।

आमतौर पर लोहे की त्रुटियां कैसे प्रकट होती हैं? टिकट " एक विकृत ज़नोड क्लिकहाउस को शुरू होने से रोकता है " गिटहब में आता है - ज़ूकिपर नोड में डेटा दूषित है।

चिड़ियाघरकीपर में, हम आम तौर पर सादे पाठ में कुछ मेटाडेटा लिखते हैं। उसके साथ कुछ गड़बड़ है - " प्रतिकृति " बहुत अजीब लिखा है।

यह शायद ही कभी होता है कि कोड में एक बग के कारण, एक बिट बदल जाता है। बेशक, हम इस तरह के एक कोड को लिख सकते हैं: हम ब्लूम फ़िल्टर लेते हैं, कुछ पते पर बिट बदलते हैं, गलत तरीके से पतों की गणना करते हैं, गलत बिट को बदलते हैं, यह कुछ डेटा पर पड़ता है। यह है कि, अब ClickHouse में यह नहीं है " प्रतिकृति" , लेकिन " repli ख एक " और उस पर सभी डेटा गलत है। लेकिन आमतौर पर, एक बिट में बदलाव लोहे की समस्याओं का एक लक्षण है।

शायद आप बिटस्क्वाटिंग का उदाहरण जानते हैं। एर्टोम डिनबर्ग ने एक प्रयोग किया : इंटरनेट पर ऐसे डोमेन हैं जिनमें बहुत अधिक ट्रैफ़िक है, हालांकि उपयोगकर्ता अपने आप इन डोमेन पर नहीं जाते हैं। उदाहरण के लिए, इस तरह के एक डोमेन FB-CDN.com एक फेसबुक सीडीएन है।

अर्टोम ने एक समान डोमेन (और कई अन्य) पंजीकृत किए, लेकिन एक बिट बदल दिया। उदाहरण के लिए, FB-CDN.com के बजाय FA-CDN.com। डोमेन को कहीं भी प्रकाशित नहीं किया गया था, लेकिन इसके लिए ट्रैफ़िक आया था। कभी-कभी FB-CDN होस्ट HTTP हेडर में लिखा जाता था, और यह अनुरोध उपयोगकर्ताओं के उपकरणों पर RAM में त्रुटियों के कारण दूसरे होस्ट में चला गया। त्रुटि सुधार के साथ रैम हमेशा मदद नहीं करता है। कभी-कभी यह हस्तक्षेप भी करता है और कमजोरियों की ओर जाता है (रोहामर, ईसीसीप्लोइट, रैमबेल्ड के बारे में पढ़ें)।

निष्कर्ष: हमेशा डेटा को स्वयं देखें।

फ़ाइल सिस्टम पर लिखते समय, बिना असफलता के चेक-योग करें। जब नेटवर्क पर संचारित हो रहा है, तो चेक-सारांश भी करें - यह उम्मीद न करें कि वहां कोई चेक-सम हैं।

अधिक कीड़े! ..

उत्पादन क्लस्टर मेट्रिक्स । अनुरोध के जवाब में उपयोगकर्ताओं को कभी-कभी अपवाद मिलता है: "चेकसम मेल नहीं करता है: दूषित डेटा" - चेक राशि सही नहीं है, डेटा दूषित है।

त्रुटि संदेश विस्तृत डेटा प्रदर्शित करता है: चेक राशि क्या अपेक्षित थी, चेक राशि वास्तव में इस डेटा में है, उस ब्लॉक का आकार जिसके लिए हम चेक राशि और अपवाद संदर्भ की जांच करते हैं।

जब हमने कुछ सर्वर से नेटवर्क पर पैकेट प्राप्त किया, तो एक अपवाद दिखाई दिया - यह परिचित दिखता है। शायद फिर से स्मृति, दौड़ की स्थिति, या कुछ और के माध्यम से गुजर रहा है।

यह अपवाद 2015 में दिखाई दिया। बग को ठीक किया गया था, यह अब दिखाई नहीं दिया। फरवरी 2019 में, वह अचानक फिर से दिखाई दिया। इस समय मैं एक सम्मेलन में था, मेरे साथियों ने इस समस्या से निपटा। ClickHouse के साथ 1000 सर्वरों के बीच एक दिन में कई बार त्रुटि को पुन: प्रस्तुत किया गया था: एक सर्वर पर आंकड़े एकत्र करना संभव नहीं है, फिर दूसरे पर। इसी समय, इस समय कोई नई रिलीज़ नहीं हुई थी। यह काम नहीं करता था और समस्या को हल करता था, लेकिन कुछ दिनों के बाद त्रुटि स्वयं गायब हो गई।

वे त्रुटि के बारे में भूल गए, और 15 मई 2019 को दोहराया। हमने उससे निपटना जारी रखा। मैंने जो पहली चीज़ की, वह सभी उपलब्ध लॉग और ग्राफ़ को देखता था। उसने पूरे दिन उनका अध्ययन किया, कुछ भी नहीं समझा, कोई पैटर्न नहीं पाया। यदि समस्या को पुन: प्रस्तुत नहीं किया जा सकता है, तो एकमात्र विकल्प सभी मामलों को इकट्ठा करना है, पैटर्न देखेंऔर व्यसनों। शायद लिनक्स कर्नेल प्रोसेसर के साथ सही ढंग से काम नहीं करता है, गलत तरीके से किसी भी रजिस्टर को बचाता है या लोड करता है।

परिकल्पना और पैटर्न

E5-2683 v4 के साथ 9 में से 7 सर्वर विफल रहे। लेकिन त्रुटि प्रवण E5-2683 v4 का केवल आधा हिस्सा एक खाली परिकल्पना है।

गलतियां आमतौर पर दोहराई नहीं जाती हैं । Mtauxyz क्लस्टर के अलावा, जहां वास्तव में दूषित डेटा (डिस्क पर खराब डेटा) है। यह एक और मामला है, हम परिकल्पना को अस्वीकार करते हैं।

त्रुटि लिनक्स कर्नेल पर निर्भर नहीं होती है - विभिन्न सर्वरों पर जांच की जाती है, कुछ भी नहीं मिला। कुछ भी दिलचस्प नहीं kern.log में, machine check exceptionकोई संदेश नहीं। नेटवर्क ग्राफिक्स में, जिसमें रिट्रांसमीटर, सीपीयू, आईओ, नेटवर्क शामिल हैं, कुछ भी दिलचस्प नहीं है। सर्वर पर सभी नेटवर्क एडेप्टर, जिस पर त्रुटियां होती हैं और दिखाई नहीं देते हैं, समान हैं।

कोई पैटर्न नहीं हैं । क्या करें? पैटर्न की तलाश जारी रखें। दूसरा प्रयास।

मैं अपटाइम सर्वरों को देखता हूं:uptime उच्च है, सर्वर stably , segfault और ऐसा कुछ नहीं है काम करते हैं। मैं हमेशा आनन्दित होता हूं जब मैं देखता हूं कि कार्यक्रम सेगफॉल्ट के साथ दुर्घटनाग्रस्त हो गया - कम से कम दुर्घटनाग्रस्त हो गया। इससे भी बदतर, जब कोई त्रुटि होती है, तो यह कुछ खराब कर देता है, लेकिन कोई इसे नोटिस नहीं करता है।

त्रुटियों को दिन के आधार पर वर्गीकृत किया जाता है और कुछ दिनों के भीतर होता है। कुछ 2 दिनों में, अधिक दिखाई देते हैं, कुछ कम में, फिर और अधिक - त्रुटियों की घटना के समय को सटीक रूप से निर्धारित करना संभव नहीं है।

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

कोई सर्वर पैटर्न नहींजहां से हम डेटा पढ़ते हैं। संकुचित ब्लॉक का आकार जिसे हम चेक-योग करते हैं, एक किलोबाइट से कम है। HEX में पैकेज के आकार को देखा। यह मेरे लिए उपयोगी नहीं था - पैकेट आकार और चेक रकम का द्विआधारी प्रतिनिधित्व ध्यान देने योग्य नहीं है।

मैंने त्रुटि को ठीक नहीं किया - मैं फिर से पैटर्न की तलाश कर रहा था। तीसरा प्रयास।

किसी कारण से, त्रुटि केवल एक क्लस्टर पर दिखाई देती है - व्लादिमीर डीसी में तीसरे प्रतिकृतियां पर (हम शहर के नाम से डेटा केंद्रों को कॉल करना पसंद करते हैं)। फरवरी 2019 में, व्लादिमीर डीसी में भी एक त्रुटि दिखाई दी, लेकिन क्लिकहाउस के एक अलग संस्करण पर। यह परिकल्पना के खिलाफ एक और तर्क है कि हमने गलत कोड लिखा था। हमने फरवरी से मई तक इसे पहले से ही तीन बार लिखा है - त्रुटि शायद कोड में नहीं है ।

नेटवर्क पर पैकेट पढ़ते समय सभी त्रुटियां -while receiving packet from। जिस पैकेज पर त्रुटि हुई, वह अनुरोध की संरचना पर निर्भर करता है। अनुरोधों के लिए जो संरचना में भिन्न हैं, विभिन्न चेक रकमों पर एक त्रुटि। लेकिन अनुरोधों में जहां त्रुटि एक ही चेक राशि पर होती है, स्थिरांक भिन्न होते हैं।

एक त्रुटि के साथ सभी अनुरोधों, एक को छोड़कर, कर रहे हैं GLOBAL JOIN। लेकिन तुलना के लिए, एक असामान्य रूप से सरल अनुरोध है, और इसके लिए संकुचित ब्लॉक आकार केवल 75 बाइट्स है।

SELECT max(ReceiveTimestamp) FROM tracking_events_all 
WHERE APIKey = 1111 AND (OperatingSystem IN ('android', 'ios'))

हम प्रभाव की परिकल्पना को खारिज करते हैं GLOBAL JOIN।

सबसे दिलचस्प है कि प्रभावित सर्वर है उनके नाम से श्रेणियों में वर्गीकृत किया है :
mtxxxlog01-{39..44 57..58 64 68..71 73..74 76}-3।

मैं थका हुआ और हताश था, पूरी तरह से भ्रम पैटर्न की तलाश करने लगा। यह अच्छा है कि मुझे अंक विज्ञान का उपयोग करके कोड डीबग करना नहीं मिला। लेकिन अभी भी लीड थे।

फरवरी में समस्या सर्वरों के समूह समान हैं।
समस्या सर्वर डेटा सेंटर के कुछ हिस्सों में स्थित हैं। डीसी व्लादिमीर में तथाकथित लाइनें हैं - इसके अलग-अलग हिस्से: वीएलए -02, वीएलए -03, वीएलए -04। त्रुटियों को स्पष्ट रूप से समूहीकृत किया जाता है: कुछ कतारों में यह अच्छा है (VLA-02), अन्य समस्याओं में (VLA-03, VLA-04)।

टाइपिंग डीबगिंग

यह केवल "भाला" विधि का उपयोग करके डीबग करने के लिए बना रहा। इसका अर्थ है परिकल्पना "यदि आप ऐसा करने की कोशिश करते हैं तो क्या होता है?" और डेटा एकत्र करते हैं। उदाहरण के लिए, मुझे उस तालिका में query_logत्रुटि के साथ एक सरल क्वेरी मिली, जिसके लिए पैकेट का आकार size of compressed blockबहुत छोटा है (= 107)।

मैंने अनुरोध लिया, इसे कॉपी किया और क्लिकहाउस-लोकल का उपयोग करके इसे मैन्युअल रूप से निष्पादित किया।

strace -f -e trace=network -s 1000 -x \
clickhouse-local --query "
    SELECT uniqIf(DeviceIDHash, SessionType = 0)
    FROM remote('127.0.0.{2,3}', mobile.generic_events)
    WHERE StartDate = '2019-02-07' AND APIKey IN (616988,711663,507671,835591,262098,159700,635121,509222)
        AND EventType = 1 WITH TOTALS" --config config.xml

स्ट्रेस की मदद से मुझे नेटवर्क पर ब्लॉकों का एक स्नैपशॉट (डंप) प्राप्त हुआ - ठीक वही पैकेट जो इस अनुरोध के निष्पादित होने पर प्राप्त होते हैं, और मैं उनका अध्ययन कर सकता हूं। आप इसके लिए tcpdump का उपयोग कर सकते हैं, लेकिन यह असुविधाजनक है: उत्पादन ट्रैफ़िक से किसी विशिष्ट अनुरोध को अलग करना कठिन है।

स्ट्रेस का उपयोग करके, आप खुद ही ClickHouse सर्वर का पता लगा सकते हैं। लेकिन यह सर्वर उत्पादन में काम करता है, अगर मैं ऐसा करता हूं तो मुझे समझ से बाहर की जानकारी मिलेगी। इसलिए, मैंने एक अलग प्रोग्राम लॉन्च किया जो बिल्कुल एक अनुरोध पर अमल करता है। पहले से ही इस कार्यक्रम के लिए मैं स्ट्रेस चलाता हूं और प्राप्त करता हूं जो नेटवर्क पर प्रसारित किया गया था।

अनुरोध त्रुटियों के बिना निष्पादित किया जाता है - त्रुटि को पुन: प्रस्तुत नहीं किया जाता है । यदि पुन: पेश किया जाता है, तो समस्या का समाधान किया जाएगा। इसलिए, मैंने पैकेटों को एक पाठ फ़ाइल में कॉपी किया और मैन्युअल रूप से प्रोटोकॉल को पार्स करना शुरू कर दिया।

चेक राशि उम्मीद के मुताबिक ही थी। यह ठीक वह पैकेज है जिस पर कभी-कभी, अन्य समयों में, अन्य अनुरोधों में, त्रुटियां हुईं। लेकिन अभी तक इसमें कोई त्रुटि नहीं हुई है।

मैंने एक साधारण प्रोग्राम लिखा था जो एक पैकेज लेता है और प्रत्येक बाइट में एक बिट को बदलने पर चेक राशि की जांच करता है। कार्यक्रम ने हर संभव स्थिति में थोड़ा फ्लिप किया और चेक राशि को पढ़ा।

मैंने कार्यक्रम शुरू किया और पाया कि यदि आप एक बिट के मूल्य को बदलते हैं, तो आप बिल्कुल उस टूटी हुई चेक-राशि को प्राप्त करते हैं, जिसके लिए शिकायत है

हार्डवेयर की समस्या

यदि सॉफ़्टवेयर में कोई त्रुटि है (उदाहरण के लिए, मेमोरी के माध्यम से ड्राइविंग), तो सिंगल बिट फ्लिप की संभावना नहीं है। इसलिए, एक नई परिकल्पना दिखाई दी - समस्या ग्रंथि में है।

कोई लैपटॉप का ढक्कन बंद कर सकता है और कह सकता है: "समस्या हमारी तरफ नहीं है, लेकिन हार्डवेयर में, हम ऐसा नहीं करते हैं।" लेकिन नहीं, आइए समझने की कोशिश करें कि समस्या कहां है: रैम में, हार्ड ड्राइव पर, प्रोसेसर में, नेटवर्क कार्ड में या नेटवर्क उपकरण में नेटवर्क कार्ड रैम में।

हार्डवेयर समस्या का स्थानीयकरण कैसे करें?

समस्या उत्पन्न हुई और कुछ तिथियों पर गायब हो गई।
प्रभावित सर्वरों को उनके नाम से समूहीकृत किया जाता है mtxxxlog01-{39..44 57..58 64 68..71 73..74 76}-3:।
समस्या सर्वर के समूह फरवरी के समान हैं।
समस्या सर्वर केवल डेटा सेंटर की कुछ कतारों में हैं।

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

समस्या हल हो गई है, लेकिन सवाल अभी भी (इंजीनियरों के लिए नहीं रह गए हैं)।

ईसीसी (त्रुटि सुधार मेमोरी) नेटवर्क स्विच पर मदद क्यों नहीं करता है? क्योंकि कई बिट फ्लिप एक दूसरे की भरपाई कर सकते हैं - आपको एक अनिर्धारित त्रुटि मिलती है।

टीसीपी चेक sums मदद क्यों नहीं करते? वे कमजोर हैं। यदि डेटा में केवल एक बिट बदल गया है, तो टीसीपी चेक सोम्स हमेशा परिवर्तन देखेंगे। यदि दो बिट्स बदल गए हैं, तो परिवर्तनों का पता नहीं लगाया जा सकता है - वे एक दूसरे को रद्द करते हैं।

हमारे पैकेज में केवल एक बिट बदल गया है, लेकिन त्रुटि दिखाई नहीं दे रही है। ऐसा इसलिए है क्योंकि टीसीपी सेगमेंट में 2 बिट्स बदल गए हैं: उन्होंने इससे चेक राशि की गणना की, यह मेल खाता था। लेकिन एक टीसीपी खंड में हमारे आवेदन का एक से अधिक पैकेट स्थित है। और उनमें से एक के लिए, हम पहले से ही अपनी जांच-राशि पर विचार करते हैं। इस पैकेट में केवल एक बिट बदल गया है।

ईथरनेट चेक sums मदद क्यों नहीं करते - क्या वे टीसीपी से अधिक मजबूत हैं? ईथरनेट चेक राशिडेटा की जाँच करें ताकि वे एक खंड के माध्यम से संचरण के दौरान टूट न जाएं (मैं शब्दावली के साथ गलत हो सकता हूं, मैं एक नेटवर्क इंजीनियर नहीं हूं)। नेटवर्क उपकरण इन पैकेटों को आगे बढ़ाते हैं और अग्रेषण के दौरान कुछ डेटा को अग्रेषित कर सकते हैं। इसलिए, चेक राशियों को बस रिकॉल किया जाता है। हमने जाँच की - तार पर पैकेज नहीं बदले हैं। लेकिन अगर वे नेटवर्क स्विच पर खुद को हराते हैं, तो यह चेक राशि (यह अलग होगा) को पुनर्गणना करेगा, और पैकेट को आगे बढ़ाएगा।

आपके पास कुछ भी नहीं बचेगा - चेक-योग स्वयं। किसी से यह अपेक्षा न करें कि वह आपके लिए ऐसा करेगा।

डेटा ब्लॉक के लिए, 128-बिट चेक योग माना जाता है (यह केवल मामले में ओवरकिल है)। हम उपयोगकर्ता को त्रुटि के बारे में सही ढंग से सूचित करते हैं। डेटा नेटवर्क पर प्रसारित होता है, यह क्षतिग्रस्त है, लेकिन हम इसे कहीं भी रिकॉर्ड नहीं करते हैं - हमारा सारा डेटा क्रम में है, आप चिंता नहीं कर सकते।

ClickHouse में संग्रहीत डेटा सुसंगत रहता है। ClickHouse में चेक रकम का उपयोग करें। हमें चेक सेम्स से इतना प्यार है कि हम तुरंत तीन विकल्पों पर विचार करते हैं:

फ़ाइल को नेटवर्क पर लिखते समय संकुचित डेटा ब्लॉक के लिए।
कुल जांच सामंजस्य सत्यापन के लिए संपीड़ित डेटा का योग है।
कुल जाँच सामंजस्य सत्यापन के लिए असंपीड़ित डेटा का योग है।

डेटा संपीड़न एल्गोरिदम में कीड़े हैं, यह एक ज्ञात मामला है। इसलिए, जब डेटा को दोहराया जाता है, तो हम संपीड़ित डेटा की कुल चेक राशि और असम्पीडित डेटा की कुल राशि पर भी विचार करते हैं।

चेक की मात्रा गिनने से डरो मत, वे धीमा नहीं करते हैं।

बेशक, यह निर्भर करता है कि किन लोगों को और कैसे गिनना है। बारीकियां हैं, लेकिन चेक राशि पर विचार करना सुनिश्चित करें। उदाहरण के लिए, यदि आप संपीड़ित डेटा से गणना करते हैं, तो कम डेटा होगा, वे धीमा नहीं होंगे।

त्रुटि संदेश में सुधार हुआ

उपयोगकर्ता को कैसे समझाया जाए जब वह इस तरह का त्रुटि संदेश प्राप्त करता है कि यह एक हार्डवेयर समस्या है?

यदि चेक राशि मेल नहीं खाती है, तो अपवाद भेजने से पहले, मैं हर मामले को बदलने की कोशिश करता हूं - बस मामले में। यदि चेक राशि बदलते समय और एक बिट में परिवर्तित हो जाती है, तो समस्या सबसे अधिक संभावना हार्डवेयर है।

यदि हम इस त्रुटि का पता लगा सकते हैं, और यदि यह बदल जाता है जब एक बिट बदल जाता है, तो इसे ठीक क्यों नहीं करें? हम ऐसा कर सकते हैं, लेकिन अगर हम हर समय त्रुटियों को ठीक करते हैं, तो उपयोगकर्ता को पता नहीं चलेगा कि उपकरण एक समस्या में है।

जब हमें पता चला कि स्विच में समस्याएं हैं, तो अन्य विभागों के लोग रिपोर्ट करने लगे: “और हमारे पास एक गलत तरीके से मैंगो लिखा है! और कुछ हमें PostgreSQL में मिला! " यह अच्छा है, लेकिन समस्याओं की रिपोर्ट करना बेहतर है।

जब हमने एक नया डायग्नोस्टिक विमोचन जारी किया, तो पहला उपयोगकर्ता जिसके साथ उसने एक सप्ताह बाद काम किया था: "यहाँ संदेश है - समस्या क्या है?" दुर्भाग्य से, उन्होंने इसे नहीं पढ़ा। लेकिन मैंने 99% संभावना के साथ पढ़ा और सुझाव दिया कि यदि त्रुटि एक सर्वर पर दिखाई देती है, तो समस्या हार्डवेयर के साथ है। मैं शेष प्रतिशत छोड़ देता हूं यदि मैंने कोड गलत लिखा था - ऐसा होता है। नतीजतन, उपयोगकर्ता ने एसएसडी को बदल दिया, और समस्या गायब हो गई।

डेटा में "डेलीरियम"

इस दिलचस्प और अप्रत्याशित समस्या ने मुझे चिंतित कर दिया। हमारे पास Yandex.Metrica डेटा है। एक साधारण JSON डेटाबेस में एक कॉलम में लिखा जाता है - काउंटर के जावास्क्रिप्ट कोड से उपयोगकर्ता पैरामीटर।

मैं किसी प्रकार का अनुरोध करता हूं और क्लिकहाउस सर्वर सेगफॉल्ट के साथ दुर्घटनाग्रस्त हो जाता है। स्टैक ट्रेस से, मुझे एहसास हुआ कि समस्या क्या थी - दूसरे देश से हमारे बाहरी योगदानकर्ताओं की एक ताजा प्रतिबद्धता। तय की गई, सेगफॉल्ट गायब हो गई।

मैं एक ही अनुरोध चलाता हूं: SELECTक्लिकहाउस में, JSON प्राप्त करने के लिए, लेकिन फिर से, बकवास, सब कुछ धीरे-धीरे काम करता है। मुझे JSON मिलता है, और यह 10 एमबी है। मैं इसे प्रदर्शित करता हूं और अधिक ध्यान से देखता हूं: {"jserrs": cannot find property of object undefind...और फिर बाइनरी कोड का एक मेगाबाइट बाहर गिर गया।

विचार थे कि यह फिर से स्मृति या दौड़ की स्थिति से एक मार्ग है। इस तरह के बहुत सारे बाइनरी डेटा खराब हैं, इसमें कुछ भी हो सकता है। यदि हां, तो अब मुझे पासवर्ड और निजी कुंजियाँ मिलेंगी। लेकिन मुझे कुछ भी नहीं मिला, इसलिए मैंने तुरंत परिकल्पना को अस्वीकार कर दिया। शायद यह ClickHouse सर्वर पर मेरे कार्यक्रम में एक बग है? शायद एक प्रोग्राम में जो लिखता है (यह C ++ में भी लिखा गया है) - अचानक वह गलती से अपनी डंप मेमोरी को क्लिकहाउस में डाल देता है? इस नरक में, मैंने पत्रों को बारीकी से देखना शुरू किया और महसूस किया कि यह इतना सरल नहीं था।

सुराग पथ

एक ही कचरा एक-दूसरे से स्वतंत्र रूप से दो समूहों में दर्ज किया गया था। डेटा कबाड़ है, लेकिन यह UTF-8 मान्य है। इस UTF-8 में कुछ अजीब URL, फ़ॉन्ट नाम, और बहुत सारे अक्षर "I" एक पंक्ति में हैं।

छोटे सिरिलिक "मैं" के बारे में क्या खास है? नहीं, यह यांडेक्स नहीं है। तथ्य यह है कि विंडोज 1251 के एन्कोडिंग में यह 255 वां चरित्र है। और हमारे लिनक्स सर्वर पर, कोई भी विंडोज़ 1251 एन्कोडिंग का उपयोग नहीं करता है।

यह पता चला है कि यह ब्राउज़र का एक डंप है: मीट्रिक काउंटर का जावास्क्रिप्ट कोड जावास्क्रिप्ट त्रुटियों को इकट्ठा करता है। जैसा कि यह निकला, जवाब सरल है - यह सभी उपयोगकर्ता से आया था ।

यहाँ से भी निष्कर्ष निकाले जा सकते हैं।

पूरे इंटरनेट से कीड़े

Yandex.Metrica इंटरनेट पर 1 बिलियन उपकरणों से ट्रैफ़िक एकत्र करता है: पीसी, सेल फ़ोन, टैबलेट पर ब्राउज़र। कचरा अनिवार्य रूप से आएगा : उपयोगकर्ता उपकरणों में कीड़े होते हैं, हर जगह अविश्वसनीय रैम और भयानक हार्डवेयर जो ओवरहीट होते हैं।

डेटाबेस 30 ट्रिलियन से अधिक लाइनों (पृष्ठ दृश्य) को संग्रहीत करता है। यदि आप इस तालिका से डेटा का विश्लेषण करते हैं, तो आप वहां कुछ भी पा सकते हैं।

इसलिए, डेटाबेस में लिखने से पहले बस इस कचरे को छानना सही है। डेटाबेस को कचरा लिखने की आवश्यकता नहीं है - उसे यह पसंद नहीं है।

HighLoad++ ( 133 ), - , , ++ PHP Russia 2020 Online.

Badoo, PHP Russia 2020 Online . PHP Russia 2020 Online 13 , .

— , .

कुख्यात कीड़े और ClickHouse के उदाहरण पर उनसे कैसे बचा जाए