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

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


Highload ++ 2017 की एक रिपोर्ट में, आंद्रेई स्मिरनोव ( smira ) ने फैसला किया कि अच्छे के बारे में बात करना दिलचस्प नहीं था, लेकिन उन्होंने हर उस समस्या के बारे में विस्तार से बात की, जिसका सामना करना था: डेटा हानि और भ्रष्टाचार के बारे में, लाश और प्रदर्शन हानि के बारे में। ये कहानियां वास्तव में रोलर कोस्टर की याद दिलाती हैं, लेकिन सभी समस्याओं के लिए एक समाधान है, जिसके लिए आप बिल्ली का स्वागत करते हैं।

स्पीकर के बारे में: एंड्री स्मिरनोव उद्यम के लिए क्लाउड स्टोरेज को लागू करने वाली कंपनी सदाचार के लिए काम करता है। यह विचार है कि सशर्त रूप से अमेज़ॅन सभी के लिए क्लाउड करता है, और Virtustream उन विशिष्ट चीजों को करता है जिनकी एक बड़ी कंपनी को आवश्यकता होती है।

सदाचार के बारे में कुछ शब्द

हम पूरी तरह से दूरस्थ छोटी टीम में काम करते हैं, और हम एक पुण्यस्ट्रीम क्लाउड समाधानों में से एक में लगे हुए हैं। यह डेटा स्टोरेज का क्लाउड है।


बहुत सरलता से बोलते हुए, यह एक S3- संगत एपीआई है जिसमें आप वस्तुओं को स्टोर कर सकते हैं। उन लोगों के लिए जो S3 नहीं जानते हैं, यह सिर्फ एक HTTP API है जिसके साथ आप ऑब्जेक्ट्स को क्लाउड पर कहीं अपलोड कर सकते हैं, उन्हें वापस ला सकते हैं, उन्हें हटा सकते हैं, ऑब्जेक्ट की एक सूची प्राप्त कर सकते हैं, आदि। आगे - इन सरल कार्यों के आधार पर अधिक जटिल विशेषताएं।

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

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

1. डीसी की विफलता या कनेक्टिविटी के नुकसान के मामले में भंडारण, पढ़ने और लिखने की अधिक विश्वसनीयता;
   
2. भले ही DC में से कोई एक फेल हो;
   
3. संचालन को "निकटतम" डीसी पर पुनर्निर्देशित करना।
   

यह एक दिलचस्प अवसर है - भले ही ये डीसी भौगोलिक रूप से बहुत दूर हैं, फिर भी उनमें से कुछ समय में अलग-अलग बिंदुओं पर ग्राहक के करीब हो सकते हैं। और निकटतम डीसी तक डेटा तक पहुंच बस तेज है।


निर्माण को विभाजित करने के लिए, जिसके बारे में हम भागों में बात करेंगे, मैं उन वस्तुओं को प्रस्तुत करूँगा जो दो बड़े टुकड़ों के रूप में क्लाउड में संग्रहीत हैं:

1. किसी वस्तु का पहला सरल टुकड़ा डेटा है । वे अपरिवर्तित हैं, उन्हें एक बार डाउनलोड किया गया था। केवल एक चीज जो बाद में उनके साथ हो सकती है वह यह है कि हम उन्हें हटा सकते हैं यदि उन्हें अब ज़रूरत नहीं है।

हमारी पिछली परियोजना डेटा के निकास के भंडारण से संबंधित थी, इसलिए हमें डेटा भंडारण में कोई समस्या नहीं थी। यह हमारे लिए पहले से ही एक सुलझा हुआ कार्य था।

2. मेटाडेटा । सभी व्यावसायिक तर्क, सभी सबसे दिलचस्प, प्रतियोगिता से संबंधित: पहुंच, रिकॉर्ड, फिर से लिखना - मेटाडेटा क्षेत्र में।

ऑब्जेक्ट के बारे में मेटाडेटा प्रोजेक्ट की सबसे बड़ी जटिलता को अपने आप में ले लेता है, मेटाडेटा ऑब्जेक्ट के संग्रहीत डेटा के ब्लॉक के लिए एक पॉइंटर को संग्रहीत करता है।

उपयोगकर्ता के दृष्टिकोण से, यह एक एकल वस्तु है, लेकिन हम इसे दो भागों में विभाजित कर सकते हैं। आज मैं केवल मेटाडेटा के बारे में बात करूंगा।

आंकड़े

• डेटा : 4 Pbytes।
• मेटाडाटा क्लस्टर : 3।
• ऑब्जेक्ट : 40 बिलियन।
• मेटाडेटा का आकार : 160 टीबी (प्रतिकृति सहित)।
• परिवर्तन की दर (मेटाडेटा): 3000 ऑब्जेक्ट्स / एस।

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

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

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

ये आंकड़े पहले से ही एक कार्य प्रणाली से प्राप्त किए गए थे, लेकिन चलिए क्लाउड स्टोरेज को डिज़ाइन करने के समय पर थोड़ा पीछे चलते हैं।

मेटाडेटा के लिए एक भंडार चुनना

जब हमें इस चुनौती का सामना करना पड़ा कि हम भू-क्षेत्रों, सक्रिय-सक्रिय होना चाहते हैं, और हमें मेटाडेटा को कहीं स्टोर करने की आवश्यकता है, तो हमने सोचा कि यह हो सकता है?

जाहिर है, रिपॉजिटरी (डेटाबेस) में निम्नलिखित गुण होने चाहिए:

• सक्रिय-सक्रिय समर्थन ;
• अनुमापकता।

हम वास्तव में चाहेंगे कि हमारा उत्पाद बेहद लोकप्रिय हो, और हम नहीं जानते कि यह एक ही समय में कैसे बढ़ेगा, इसलिए सिस्टम को स्केल करना चाहिए।

• दोष सहिष्णुता और भंडारण विश्वसनीयता का संतुलन।

मेटाडेटा को सुरक्षित रूप से संग्रहीत किया जाना चाहिए, क्योंकि अगर हम उन्हें खो देते हैं, और उनमें डेटा का लिंक होता है, तो हम पूरी वस्तु खो देंगे।

• संचालन की अनुकूलन स्थिरता।

इस तथ्य के कारण कि हम कई डीसी में काम करते हैं और इस संभावना को अनुमति देते हैं कि डीसी अनुपलब्ध हो सकते हैं, इसके अलावा, डीसी एक दूसरे से बहुत दूर हैं, हम अधिकांश एपीआई संचालन के दौरान, इस ऑपरेशन को एक साथ करने की आवश्यकता नहीं कर सकते हैं दो डीसी। यदि दूसरा डीसी अनुपलब्ध है तो यह बहुत धीमा और असंभव होगा। इसलिए, ऑपरेशन का हिस्सा स्थानीय रूप से एक डीसी में काम करना चाहिए।

लेकिन, स्पष्ट रूप से, कुछ समय में किसी प्रकार का अभिसरण होना चाहिए, और सभी संघर्षों को हल करने के बाद, डेटा को दोनों डेटा केंद्रों में दिखाई देना चाहिए। इसलिए, संचालन की स्थिरता को समायोजित किया जाना चाहिए।

मेरे दृष्टिकोण से, कैसंड्रा इन आवश्यकताओं के लिए उपयुक्त है।

कैसेंड्रा

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

कैसंड्रा क्या है?

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

यदि कैसेंड्रा को एक परत केक की तरह स्तरित किया गया था, तो मैं 3 परतों का चयन करूंगा:

1. प्रत्येक नोड पर स्थानीय केवी भंडारण।
यह नोड्स का एक समूह है, जिनमें से प्रत्येक स्थानीय स्तर पर कुंजी-मूल्य डेटा संग्रहीत कर सकता है।

2. नोड्स पर डेटा साझा करना (लगातार हैशिंग)।
कैसेंड्रा प्रतिकृति सहित क्लस्टर के नोड्स के बीच डेटा वितरित कर सकता है, और यह इस तरह से करता है कि क्लस्टर आकार में बढ़ या घट सकता है, और डेटा को पुनर्वितरित किया जाएगा।

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


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

सिद्धांत रूप में ये रोलर कोस्टर, आज तक समाप्त नहीं हुए हैं।

एक अच्छा

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

कैसंड्रा वास्तव में अच्छा है।

• यह उन प्रणालियों में से एक है जो हमें मिलीसेकंड में प्रतिक्रिया समय देने की अनुमति देता है, अर्थात, स्पष्ट रूप से 10 एमएस से कम है। यह हमारे लिए अच्छा है, क्योंकि सामान्य रूप से प्रतिक्रिया समय हमारे लिए महत्वपूर्ण है। हमारे लिए मेटाडेटा के साथ संचालन किसी भी वस्तु के भंडारण से संबंधित किसी भी ऑपरेशन का हिस्सा है, चाहे वह प्राप्त हो या रिकॉर्डिंग।
• रिकॉर्डिंग के दृष्टिकोण से, उच्च मापनीयता हासिल की जाती है। आप कैसंड्रा में एक पागल गति से लिख सकते हैं, और कुछ स्थितियों में यह आवश्यक है, उदाहरण के लिए, जब हम रिकॉर्ड के बीच बड़ी मात्रा में डेटा स्थानांतरित करते हैं।
• कैसंड्रा वास्तव में गलती सहिष्णु है । एक नोड के गिरने से तुरंत समस्याएं नहीं होती हैं, हालांकि जितनी जल्दी या बाद में वे शुरू हो जाएंगे। कैसेंड्रा ने घोषणा की कि इसमें विफलता का एक भी बिंदु नहीं है, लेकिन, वास्तव में, हर जगह विफलता के बिंदु हैं। वास्तव में, जो डेटाबेस के साथ काम करता था वह जानता है कि एक नोड दुर्घटना भी ऐसी चीज नहीं है जो आमतौर पर सुबह तक होती है। आमतौर पर, इस स्थिति को तेजी से ठीक करने की आवश्यकता होती है।
• सादगी। फिर भी, अन्य मानक कैसंड्रा रिलेशनल डेटाबेस की तुलना में, यह समझना आसान है कि क्या हो रहा है। बहुत बार, कुछ गलत हो जाता है, और हमें यह समझने की आवश्यकता है कि क्या हो रहा है। कैसेंड्रा के पास यह पता लगाने की अधिक संभावनाएं हैं, सबसे छोटा पेंच प्राप्त करें, शायद, किसी अन्य डेटाबेस की तुलना में।

पांच बुरी कहानियां

मैं दोहराता हूं, कैसंड्रा अच्छा है, यह हमारे लिए काम करता है, लेकिन मैं पांच कहानियों के बारे में बताऊंगा। मुझे लगता है कि यह वही है जिसके लिए आप इसे पढ़ते हैं। मैं कहानियों को कालानुक्रमिक क्रम में दूंगा, हालांकि वे एक दूसरे के साथ बहुत जुड़े नहीं हैं।


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

यह कैसे होता है, यह समझाने के लिए, मुझे इस बारे में थोड़ी बात करनी होगी कि हमारे अंदर सब कुछ कैसे व्यवस्थित है।


S3 के नजरिए से, कुछ बुनियादी चीजें हैं:

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

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

इसलिए, हमारे पास दो बेस टेबल हैं:

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

आंकड़ा उदाहरणों से पता चलता है कि वस्तुओं के टेबल और ऑब्जेक्ट के संस्करण कैसे संबंधित हैं।


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

एक समस्या थी।


समस्या यह थी: हमारे पास सक्रिय-सक्रिय, दो डीसी हैं। प्रत्येक डीसी में, मेटाडेटा तीन प्रतियों में संग्रहीत किया जाता है, अर्थात्, हमारे पास 3 + 3 - केवल 6 प्रतिकृतियां हैं। जब ग्राहक हमसे संपर्क करते हैं, तो हम स्थिरता के साथ संचालन करते हैं (कैसेंड्रा के दृष्टिकोण से इसे LOCAL_QUORUM कहा जाता है)। यही है, यह गारंटी है कि रिकॉर्ड (या पढ़ा) स्थानीय डीसी में 2 प्रतिकृतियां में हुआ। यह एक गारंटी है - अन्यथा ऑपरेशन विफल हो जाएगा।

कैसंड्रा हमेशा सभी 6 लाइनों में लिखने की कोशिश करेगा - 99% समय सब कुछ ठीक होगा। वास्तव में, सभी 6 प्रतिकृतियां समान होंगी, लेकिन हमें 2 की गारंटी होगी।

हमारे पास एक कठिन स्थिति थी, हालांकि यह भू-क्षेत्र भी नहीं था। यहां तक ​​कि सामान्य क्षेत्रों के लिए जो एक डीसी में हैं, हमने अभी भी मेटाडेटा की दूसरी कॉपी को दूसरे डीसी में संग्रहीत किया है। यह एक लंबी कहानी है, मैं सभी विवरण नहीं दूंगा। लेकिन अंत में, हमारे पास एक सफाई प्रक्रिया थी जिसने अनावश्यक संस्करणों को हटा दिया।

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

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


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

बेशक, आगे एक "बूम" है, क्योंकि हमारे पास अभी भी वस्तुओं की तालिका में एक रिकॉर्ड है जो एक संस्करण को संदर्भित करता है जो अब मौजूद नहीं है।

इसलिए पहली बार जब हमने डेटा खो दिया, और हमने इसे वास्तव में खो दिया - बिलकुल नहीं - अच्छा, थोड़ा।

निर्णय

क्या करें? हमारी स्थिति में, सब कुछ सरल है।

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

संगति सभी में कैसेंड्रा की एक विशेषता है। 2. कैसंड्रा 3 में, सब कुछ थोड़ा बेहतर है - एक सुसंगतता का स्तर है, जिसे प्रत्येक डीसी में कोरम कहा जाता है। लेकिन किसी भी मामले में, यह समस्या है कि यह धीमा है , क्योंकि, सबसे पहले, हमें दूरस्थ डीसी की ओर मुड़ना होगा। दूसरे, सभी 6 नोड्स की स्थिरता के मामले में, इसका मतलब है कि यह इन 6 नोड्स में से सबसे खराब गति से काम करता है।

लेकिन एक ही समय में, तथाकथित रीड-रिपेयर प्रक्रिया तब होती है, जब सभी प्रतिकृतियां समकालिक नहीं होती हैं। यही है, जब रिकॉर्डिंग कहीं विफल हो गई, तो यह प्रक्रिया एक साथ उन्हें मरम्मत करती है। कैसे कैसंड्रा काम करता है।

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

अचानक हमने पाया कि हमारे पास इस तरह के 10% रिकॉर्ड हैं । कुछ भी बदतर नहीं, शायद, अगर हम अनुमान नहीं लगा सकते थे कि यह मामला नहीं था। समस्या अलग थी।



लाश हमारे डेटाबेस में है। यह इस समस्या का अर्ध-आधिकारिक नाम है। यह समझने के लिए कि यह क्या है, आपको इस बारे में बात करने की जरूरत है कि कैसंड्रा में कैसे काम करता है।


उदाहरण के लिए, हमारे पास डेटा एक्स का कुछ टुकड़ा है जो रिकॉर्ड किया गया है और पूरी तरह से सभी 6 प्रतिकृतियों को दोहराया गया है। अगर हम इसे हटाना चाहते हैं, तो कैसंड्रा में किसी भी ऑपरेशन की तरह हटाने, सभी नोड्स पर प्रदर्शन नहीं किया जा सकता है।

उदाहरण के लिए, हम एक डीसी में 3 में से 2 की स्थिरता की गारंटी देना चाहते थे। डिलीट ऑपरेशन को पांच नोड्स पर निष्पादित करें, लेकिन एक रिकॉर्ड पर रहें, उदाहरण के लिए, क्योंकि नोड उस समय उपलब्ध नहीं था।


यदि हम इसे हटा देते हैं और फिर उसी स्थिरता के साथ "मुझे 3 में से 2 चाहिए" पढ़ने की कोशिश करते हैं, तो कैसंड्रा, मूल्य और इसकी अनुपस्थिति को देखते हुए, इसे डेटा की उपस्थिति के रूप में व्याख्या करता है। यही है, जब वापस पढ़ने, वह कहेगी: "ओह, डेटा है!", हालांकि हमने उन्हें हटा दिया। इसलिए, आप इस तरह से हटा नहीं सकते।


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

Tombstone — , , , , - , . Tombstone . Tombstone gc_grace_period . , , .

?

Repair

Cassandra , Repair (). — , . , , , , / , , - - , .. . Repair , .


, - , - . Repair , , . - , — . , .


Repair, , , , — , . 6 . — , , .


, — , - . , . , - , , , .

निर्णय

, :

• Repair .

, repair. , , .

• , Tombstones, , repair.

repair — , repair. , , 10-20 , , 3 . Tombstone , . , , -.


Cassandra, . .

S3 . , — 10 , 100 . API, — . , , , , , . , , , — , . .

API?


, — , , — , , . . — . , , . , , Cassandra. , — , , , .

, , , , . , . , , . , - , .

Cassandra , . , , , , , .


, Cassandra composite key . , — , - , — . , . ? , , !

, , , , — , .

. Cassandra , Cassandra . , , Cassandra, : , , SQL .. !


. Cassandra ? , , API. , , , , ( ) . , .

, . , , , . , — — . , , , .

Cassandra , . : « 100 », , , , , , 100, .

, ( ), — , , . , , , , , - . 100 , - , , . , SQL .

Cassandra , , Java, . , Large Partition , . — , , , , — . , , garbage collection .. .

, , , , .

, , - .


, , . . , Large Partition.

:

1. ( , - );
   
2. , , . , .
   

, , , key_hash 0. , , . , . , , .

, .


— , , , - - .

— , N ? , Large Partition, — . , . : . , , , , - . , . , , .


— , , - . - , , . , , . , , ..

— , ? , . ? - md5- — , - 30 — , - . . , , .


, , , , . — , . , . , - - - , - - — . , . .

, , , .

• .
• .
• Cassandra.
• ऑनलाइन पुनर्वितरण (संचालन और स्थिरता के नुकसान को रोकने के बिना)।

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

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

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

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

यह सब इस अर्थ में ऑनलाइन होता है कि हम ऑपरेशन को रोकते नहीं हैं। किसी भी समय आप चाबियाँ की सूची का अनुरोध कर सकते हैं, पढ़ सकते हैं, ऑपरेशन लिख सकते हैं। यह हमेशा सुसंगत होगा, भले ही हम पुनरावृत्ति की प्रक्रिया में हों।

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

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

इस तरह के ट्रिक्स आपको यह ऑनलाइन करने की अनुमति देते हैं।

निर्णय

• कभी नहीं, कभी भी एक बड़े विभाजन की उपस्थिति की अनुमति न दें ।
• कार्य के आधार पर प्राथमिक कुंजी द्वारा डेटा तोड़ें ।

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

इसके अलावा, विभाजन न केवल डेटा से, बल्कि टॉम्बस्टोन (विलोपन मार्कर) से भी बड़ा हो सकता है। कैसंड्रा इंटर्नल्स (हम उन्हें बाहर से कभी नहीं देखते हैं) के दृष्टिकोण से, हटाने वाले मार्कर भी डेटा हैं, और एक विभाजन बड़ा हो सकता है यदि इसमें बहुत सारी चीजें हटा दी जाती हैं, क्योंकि हटाना एक रिकॉर्ड है। आपको इस बारे में नहीं भूलना चाहिए।


एक और कहानी जो वास्तव में निरंतर है कि शुरुआत से अंत तक कुछ गलत हो जाता है। उदाहरण के लिए, आप देखते हैं कि कैसंड्रा से प्रतिक्रिया समय बढ़ गया है, यह धीरे-धीरे प्रतिक्रिया करता है। कैसे समझें और समझें कि समस्या क्या है? कोई बाहरी संकेत नहीं है कि समस्या है।


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

ग्राफ पर, औसत पहले से ही सैकड़ों मिलीसेकंड से अधिक हो गया है - कुछ गलत हो गया। लेकिन इस तस्वीर को देखकर, यह समझना असंभव है कि इसका कारण क्या है।



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

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

लेकिन संयोजक धीरे-धीरे जवाब क्यों देता है? शायद समस्या उसके साथ है, जैसे कि, वह धीमा हो जाता है और धीरे-धीरे जवाब देता है? या शायद वह धीमा हो जाता है, क्योंकि प्रतिकृतियां धीरे-धीरे उसका जवाब देती हैं? यदि प्रतिकृतियां धीरे-धीरे प्रतिक्रिया करती हैं, तो अनुप्रयोग के दृष्टिकोण से यह समन्वयक की धीमी प्रतिक्रिया की तरह दिखाई देगी, हालांकि इसका इससे कोई लेना-देना नहीं है।

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

व्याख्या की जटिलता

• समन्वयक प्रतिक्रिया समय (नोड बनाम प्रतिकृति खुद)।
• एक विशिष्ट तालिका या संपूर्ण नोड?
• जीसी पॉज? अपर्याप्त थ्रेड पूल?
• बहुत सारे अप्राप्य SSTables?

यह समझना हमेशा मुश्किल है कि क्या गलत है। यह केवल आवेदन पक्ष से और कैसंड्रा दोनों से ही बहुत सारे आंकड़े और निगरानी की आवश्यकता है, क्योंकि यदि यह वास्तव में खराब है, तो कैसंड्रा से कुछ भी दिखाई नहीं देता है। आप प्रत्येक विशिष्ट नोड पर, प्रत्येक विशिष्ट तालिका के स्तर पर व्यक्तिगत प्रश्नों के स्तर को देख सकते हैं।

उदाहरण के लिए, ऐसी स्थिति हो सकती है जहां कैसंड्रा SSTables (अलग फ़ाइलों) में क्या कहा जाता है की एक तालिका बहुत अधिक है। पढ़ने के लिए, कैसंड्रा ने लगभग सभी SSTables के माध्यम से सॉर्ट करने के लिए कहा है। यदि उनमें से बहुत सारे हैं, तो बस इस छँटाई की प्रक्रिया में बहुत अधिक समय लगता है, और पढ़ना शुरू होता है।

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

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

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

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

संदर्भ की समझ

समस्या के लिए हमेशा कुछ संदर्भ होता है - क्लस्टर में क्या हो रहा है, क्या रिपेयर अभी काम कर रहा है, किस नोड पर, किस प्रमुख स्थान पर, किस तालिका में है।

उदाहरण के लिए, हमारे पास लोहे के साथ हास्यास्पद समस्याएं थीं। हमने देखा कि नोड्स का हिस्सा धीमा है। यह बाद में पता चला कि इसका कारण यह था कि BIOS में उनके प्रोसेसर ऊर्जा-बचत मोड में थे। किसी कारण से, लोहे की प्रारंभिक स्थापना के दौरान, यह हुआ, और अन्य नोड्स की तुलना में लगभग 50% प्रोसेसर संसाधनों का उपयोग किया गया था।

ऐसी समस्या को समझना वास्तव में मुश्किल हो सकता है। लक्षण यह है - ऐसा लगता है कि नोड संघनन करता है, लेकिन यह धीरे-धीरे करता है। कभी-कभी यह लोहे से जुड़ा होता है, कभी-कभी नहीं, लेकिन यह सिर्फ एक और कैसंड्रा बग है।

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


नवीनतम कहानी कैसंड्रा ने डेटा को कैसे गड़बड़ कर दिया, इस बारे में है। इस स्थिति में, यह कैसंड्रा के अंदर हुआ। यह दिलचस्प था।

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

कुछ बिंदुओं पर स्पॉल्ड लाइनें दिखाई देती हैं, जैसे फ्लैश, और फिर वे कई दिनों या हफ्तों के लिए फिर से चले जाते हैं।

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

शायद एक डिस्क के साथ कुछ? क्या डिस्क पर डेटा दूषित है? फिर नहीं।

शायद एक स्मृति? नहीं! एक क्लस्टर में बिखरे हुए।

शायद यह किसी प्रकार की प्रतिकृति समस्या है? एक नोड ने सब कुछ खराब कर दिया और आगे एक खराब मूल्य दोहराया? - नहीं।

अंत में, शायद यह एक आवेदन समस्या है?

इसके अलावा, कुछ बिंदु पर, क्षतिग्रस्त लाइनें दो कैसंड्रा समूहों में दिखाई देने लगीं। एक ने 2.1 संस्करण पर काम किया, दूसरा तीसरे पर। ऐसा लगता है कि कैसंड्रा अलग है, लेकिन समस्या एक ही है। शायद हमारी सेवा खराब डेटा भेजती है? लेकिन यकीन करना मुश्किल था। कैसेंड्रा इनपुट डेटा को मान्य करता है; यह कचरा नहीं लिख सकता है। लेकिन अचानक?

कुछ भी नहीं फिट बैठता है।

एक सुई मिली!

हम एक छोटी सी समस्या का पता लगाने तक लंबे समय तक संघर्ष करते रहे: जेवीएम से नोड्स पर किसी तरह का क्रैश डंप क्यों होता है जिस पर हमने ज्यादा ध्यान नहीं दिया? और किसी तरह यह स्टैक ट्रेस कचरा कलेक्टर में संदिग्ध रूप से दिखता है ... और किसी कारण से कुछ स्टैक ट्रेस भी कचरे के साथ भरा हुआ है।

अंत में, हमने महसूस किया - ओह, किसी कारण से हम 2015 के पुराने संस्करण के जेवीएम का उपयोग कर रहे हैं । यह एकमात्र सामान्य चीज थी जिसने कैसेंड्रा के विभिन्न संस्करणों पर कैसंड्रा समूहों को एकजुट किया।

मुझे अभी भी पता नहीं है कि समस्या क्या थी, क्योंकि जेवीएम के आधिकारिक रिलीज़ नोट्स में इस बारे में कुछ भी नहीं लिखा गया था। लेकिन अद्यतन के बाद, सब कुछ गायब हो गया, समस्या अब पैदा नहीं हुई। इसके अलावा, यह पहले दिन से क्लस्टर में नहीं हुआ, लेकिन कुछ बिंदु से, हालांकि इसने लंबे समय तक एक ही जेवीएम पर काम किया।

डेटा रिकवरी

इससे हमने क्या सबक सीखा है:

● बैकअप बेकार है।
जैसा कि हमें पता चला था, यह दर्ज किए जाने के दूसरे दिन दूषित हो गया था। जिस समय डेटा समन्वयक में प्रवेश किया, वे पहले से ही दूषित थे।

● अप्रकाशित स्तंभों की आंशिक बहाली संभव है।
कुछ कॉलम क्षतिग्रस्त नहीं थे, हम इस डेटा को पढ़ सकते हैं, इसे आंशिक रूप से पुनर्स्थापित कर सकते हैं।

● अंत में, हमें विभिन्न स्रोतों से वसूली करनी पड़ी।
हमारे पास ऑब्जेक्ट में बैकअप मेटाडेटा था, लेकिन डेटा में ही। ऑब्जेक्ट के साथ पुन: कनेक्ट करने के लिए, हमने लॉग आदि का उपयोग किया।

● लॉग अनमोल हैं!
हम दूषित किए गए सभी डेटा को पुनर्प्राप्त करने में सक्षम थे, लेकिन अंत में डेटाबेस पर भरोसा करना बहुत मुश्किल है अगर यह आपके हिस्से पर कोई कार्रवाई किए बिना भी आपका डेटा खो देता है।

निर्णय

• व्यापक परीक्षण के बाद जेवीएम को अपडेट करें।
• जेवीएम क्रैश मॉनिटरिंग।
• डेटा की एक कैसेंड्रा-स्वतंत्र प्रतिलिपि रखें।

एक टिप के रूप में: किसी प्रकार के कैसंड्रा-स्वतंत्र प्रतिलिपि डेटा की कोशिश करें जिससे आप आवश्यक होने पर पुनर्प्राप्त कर सकें। यह अंतिम स्तर का समाधान हो सकता है। इसे बहुत समय लगने दें, संसाधन, लेकिन कुछ विकल्प होने चाहिए जो आपको डेटा वापस करने की अनुमति देंगे।

कीड़े

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

● जटिल सुविधाओं के साथ लगातार मुद्दे
यह सुविधा जितनी अधिक जटिल है, उतनी ही अधिक समस्याएं, बग इत्यादि।

● 2.1 में वृद्धिशील मरम्मत का उपयोग न करें
प्रसिद्ध मरम्मत, जिसके बारे में मैंने बात की थी, जो मानक मोड में, डेटा की स्थिरता को ठीक करता है, जब यह सभी नोड्स को सर्वेक्षण करता है, अच्छी तरह से काम करता है। लेकिन तथाकथित वृद्धिशील मोड में नहीं (जब मरम्मत डेटा जो पिछले मरम्मत के बाद से नहीं बदला है, जो काफी तार्किक है)। यह एक लंबे समय से पहले औपचारिक रूप से घोषित किया गया था, जैसा कि एक विशेषता मौजूद है, लेकिन हर कोई कहता है: "नहीं, संस्करण 2.1 में, कभी भी इसका उपयोग न करें! वह जरूर कुछ याद करेगा। 3 में हम इसे ठीक करते हैं। ”

● लेकिन 3.x में वृद्धिशील मरम्मत का उपयोग न करें
जब तीसरा संस्करण सामने आया, कुछ दिनों बाद उन्होंने कहा: "नहीं, आप इसे तीसरे में उपयोग नहीं कर सकते। 15 बग की एक सूची है, इसलिए किसी भी मामले में वृद्धिशील मरम्मत का उपयोग न करें। 4 वें में हम बेहतर करेंगे! ”

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

● JIRA का ट्रैक रखने की आवश्यकता है

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

मैं आपको अन्य रेक ढूंढना चाहता हूं और उन पर कदम रखना चाहता हूं, क्योंकि, मेरे दृष्टिकोण से, कोई बात नहीं, कैसंड्रा अच्छा है और निश्चित रूप से, उबाऊ नहीं है। बस सड़क पर धक्कों याद है!

हाईलाड ++ कार्यकर्ताओं की खुली बैठक

31 जुलाई को मॉस्को में, 19:00 बजे, वक्ताओं की एक बैठक , कार्यक्रम समिति और हाई-लोड सिस्टम के डेवलपर्स के हाईलाड ++ 2018 सम्मेलन के कार्यकर्ताओं की बैठक आयोजित की जाएगी। हम इस साल के कार्यक्रम के बारे में एक छोटी सी मंथन का आयोजन करेंगे ताकि नए और महत्वपूर्ण कुछ भी याद न करें। बैठक खुली है, लेकिन आपको पंजीकरण करने की आवश्यकता है।

कागजात के लिए कॉल करें

Highload ++ 2018 पर रिपोर्ट के लिए सक्रिय रूप से आवेदन स्वीकार करना । कार्यक्रम समिति गर्मियों के अंत तक आपके सार का इंतजार कर रही है।