MongoDB साझा क्लस्टर का समस्या निवारण

शार्ड की और क्लस्टर उपलब्धता का चयन करना

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

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

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

क्या होगा अगर? Mongos उदाहरण अनुपस्थित हो जाता है

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

सुनिश्चित करें कि जिस पोर्ट पर आप फिर से कनेक्ट करने का प्रयास कर रहे हैं वह भी किसी अन्य प्रक्रिया द्वारा कब्जा नहीं किया गया है।

क्या होगा अगर? एक सदस्य शार्ड रेप्लिका सेट से अनुपस्थित हो जाता है

sh.status() कमांड चलाकर शार्ड की स्थिति की जांच शुरू करें। यदि लौटाए गए परिणाम में क्लस्टर आईडी नहीं है, तो शार्ड वास्तव में अनुपलब्ध है। हमेशा उपलब्धता की रुकावटों और विफलताओं की जांच करें और यदि आप इसे कम से कम समय में पुनर्प्राप्त करने में असमर्थ हैं, तो इसे जल्द से जल्द बदलने के लिए एक नया सदस्य बनाएं ताकि अधिक डेटा हानि से बचा जा सके।

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

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

प्रारंभिक सिंक MongoDB को सक्षम करेगा...

1. को छोड़कर सभी उपलब्ध डेटाबेस को क्लोन करें स्थानीय डेटाबेस। सुनिश्चित करें कि लक्ष्य सदस्य के पास स्थानीय डेटाबेस में पर्याप्त डिस्क स्थान है ताकि डेटा की प्रतिलिपि बनाई जा रही अवधि के लिए अस्थायी रूप से ओप्लॉग रिकॉर्ड को संग्रहीत किया जा सके।
2. डेटा सेट में सभी परिवर्तन लागू करें स्रोत से oplog का उपयोग करना। प्रक्रिया तभी पूरी होगी जब प्रतिकृति की स्थिति STARTUP2 से SECONDARY में परिवर्तित हो जाएगी।

क्या होगा अगर? प्रतिकृति सेट के सभी सदस्य अनुपस्थित हैं

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

क्या होगा अगर? पुराना कॉन्‍फ़िगर डेटा कर्सर को विफल कर देता है

कभी-कभी एक mongos इंस्टेंस को कॉन्फिग डेटाबेस से मेटाडेटा कैशे को अपडेट करने में लंबा समय लग सकता है जिससे क्वेरी वापस आ जाती है चेतावनी: 

could not initialize cursor across all shards because : stale config detected

यह त्रुटि हमेशा प्रस्तुत की जाएगी जब तक कि mongos इंस्टेंस अपने कैश को रीफ्रेश नहीं करते। यह वापस आवेदन के लिए प्रचारित नहीं करना चाहिए। इसे ठीक करने के लिए आपको FluRouterConfig चलाकर इंस्टेंस को रीफ़्रेश करने के लिए बाध्य करना होगा।

एक विशिष्ट संग्रह चलाने के लिए कैश फ्लश करने के लिए

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

किसी विशिष्ट डेटाबेस रन के लिए कैश फ्लश करने के लिए 

db.adminCommand({ flushRouterConfig: "<db>" } )

सभी डेटाबेस और उनके संग्रह के लिए कैश फ्लश करने के लिए:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

क्या होगा अगर? कॉन्फिग सर्वर अनुपलब्ध हो जाता है

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

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

सदस्यों को कम से कम तीन डेटा केंद्रों में वितरित करने की सलाह दी जाती है।

एक अन्य वितरण संभावना डेटा असर करने वाले सदस्यों को दो डेटा केंद्रों और शेष सदस्यों में समान रूप से वितरित करना है बादल।

डेटाबेस स्ट्रिंग त्रुटि को ठीक करना

MongoDB 3.4 की तरह, SCCC कॉन्फिग सर्वर मिरर किए हुए mongod इंस्टेंस के लिए समर्थित नहीं हैं। यदि आपको अपने शार्प किए गए क्लस्टर को संस्करण 3.4 में अपग्रेड करने की आवश्यकता है, तो आपको कॉन्फ़िगरेशन सर्वर को SCCC से CSRS में बदलने की आवश्यकता है।

कॉन्फ़िगर सर्वर को स्थानांतरित करते समय डाउनटाइम से बचना

डाउनटाइम कुछ कारकों जैसे कि पावर आउटेज या नेटवर्क फ़्रीक्वेंसी के परिणामस्वरूप हो सकता है, जिसके परिणामस्वरूप क्लस्टर में कॉन्फ़िगरेशन सर्वर की विफलता। CNAME का उपयोग उस सर्वर की पहचान करने के लिए करें, ताकि पुनर्संयोजन के दौरान उसका नाम बदला जा सके या फिर से क्रमांकन किया जा सके। यदि माइग्रेशन प्रक्रिया के दौरान मूवचंक कमिट कमांड विफल हो जाता है, तो MongoDB त्रुटि की रिपोर्ट करेगा:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

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

निष्कर्ष

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

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