MongoDB के प्रशासन के लिए विचार

नीचे हमारे श्वेतपत्र "MongoDB प्रबंधन और क्लस्टर नियंत्रण के साथ स्वचालन" का एक अंश है जिसे मुफ्त में डाउनलोड किया जा सकता है।

MongoDB के प्रशासन के लिए विचार

अंतर्निहित अतिरेक

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

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

प्रतिकृति सेट को मैन्युअल रूप से परिनियोजित करने के लिए, उच्च-स्तरीय चरण इस प्रकार हैं:

1. प्रत्येक डेटाबेस नोड के लिए एक भौतिक या वर्चुअल होस्ट आवंटित करें, और अपने डेस्कटॉप पर MongoDB कमांड लाइन क्लाइंट स्थापित करें। एक निरर्थक प्रतिकृति सेट कॉन्फ़िगरेशन के लिए, कम से कम तीन नोड्स की आवश्यकता होती है, जिनमें से कम से कम दो डेटा नोड्स होंगे। प्रतिकृति सेट में एक नोड को एक मध्यस्थ के रूप में कॉन्फ़िगर किया जा सकता है:यह एक मोंगोड प्रक्रिया है जिसे केवल आवश्यकता पड़ने पर प्राथमिक के चुनाव में वोट प्रदान करके कोरम बनाने के लिए कॉन्फ़िगर किया गया है। डेटा को मध्यस्थ प्रक्रियाओं में दोहराया नहीं जाता है।
2. प्रत्येक नोड पर MongoDB स्थापित करें। कुछ Linux वितरणों में MongoDB सामुदायिक संस्करण शामिल है, लेकिन ध्यान रखें कि इनमें नवीनतम संस्करण शामिल नहीं हो सकते हैं। MongoDB Enterprise केवल MongoDB की वेबसाइट से डाउनलोड करके उपलब्ध है। MongoDB एंटरप्राइज़ के समान कार्यक्षमता MongoDB के लिए Percona सर्वर के माध्यम से भी उपलब्ध है, MongoDB एंटरप्राइज़ या सामुदायिक संस्करण के लिए ड्रॉप-इन प्रतिस्थापन।
3. "प्रतिकृति पैरामीटर" का उपयोग करके, अपने प्रतिकृति सेट के लिए अलग-अलग mongod.conf कॉन्फ़िगरेशन फ़ाइलों को कॉन्फ़िगर करें। यदि आप सुरक्षा के लिए कुंजी फ़ाइल का उपयोग करेंगे, तो इसे अभी भी कॉन्फ़िगर करें। ध्यान दें कि कुंजी फ़ाइल सुरक्षा का उपयोग करने से भूमिका-आधारित प्रमाणीकरण भी सक्षम होता है, इसलिए आपको सर्वर का उपयोग करने के लिए उपयोगकर्ता और भूमिकाएँ भी जोड़ने की आवश्यकता होगी। प्रत्येक सर्वर पर mongod प्रक्रिया को पुनरारंभ करें।
4. नोड्स के बीच कनेक्टिविटी सुनिश्चित करें। आपको यह सुनिश्चित करना होगा कि MongoDB प्रतिकृति सेट नोड्स पोर्ट 27017 पर एक दूसरे के साथ संचार कर सकते हैं, और यह भी कि आपका क्लाइंट एक ही पोर्ट पर प्रत्येक प्रतिकृति सेट नोड्स से जुड़ सकता है।
5. MongoDB कमांड लाइन क्लाइंट का उपयोग करके, किसी एक सर्वर से कनेक्ट करें, और अपने प्रतिकृति सेट को प्रारंभ करने के लिए rs.initiate() चलाएं, इसके बाद प्रत्येक अतिरिक्त नोड के लिए rs.add() करें। कॉन्फ़िगरेशन देखने के लिए rs.conf() का उपयोग किया जा सकता है।

हालांकि ये चरण MongoDB शार्प्ड क्लस्टर को परिनियोजित और कॉन्फ़िगर करने, या रिलेशनल डेटाबेस को शार्प करने के रूप में जटिल नहीं हैं, वे विशेष रूप से बड़े वातावरण में कठिन और त्रुटि के लिए प्रवण हो सकते हैं।

मापनीयता

क्षैतिज रूप से स्केलिंग करने की क्षमता के कारण MongoDB को अक्सर "वेब स्केल" डेटाबेस सॉफ़्टवेयर के रूप में जाना जाता है। रिलेशनल डेटाबेस की तरह, MongoDB को लंबवत रूप से स्केल करना संभव है, बस भौतिक होस्ट को अपग्रेड करके, जिस पर अधिक CPU कोर, अधिक RAM, तेज डिस्क, या यहां तक ​​​​कि बढ़ी हुई बस गति के साथ रहता है। हालांकि, लागत-लाभ अनुपात और घटते रिटर्न, और तकनीकी सीमा दोनों के संदर्भ में लंबवत स्केलिंग की अपनी सीमाएं हैं। इसे संबोधित करने के लिए, MongoDB में एक "ऑटो-शार्डिंग" सुविधा है, जो डेटाबेस को कई मेजबानों (या अतिरेक के लिए प्रतिकृति सेट) में विभाजित करने की अनुमति देती है। जबकि रिलेशनल प्लेटफॉर्म पर शार्डिंग भी संभव है, जब तक कि डेटाबेस की स्थापना के लिए डिज़ाइन नहीं किया गया हो, इसके लिए प्रमुख स्कीमा और एप्लिकेशन रिडिजाइन की आवश्यकता होती है, साथ ही क्लाइंट एप्लिकेशन रिडिजाइन, जिससे यह एक थकाऊ, समय लेने वाली और त्रुटि-प्रवण प्रक्रिया बन जाती है।

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

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

मध्यस्थ

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

विलंबित प्रतिकृति सेट सदस्य

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

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

बैकअप

प्रतिकृति सेट या शार्प क्लस्टर का बैकअप "मोंगोडम्प" कमांड लाइन उपयोगिता के माध्यम से किया जाता है। जब --oplog पैरामीटर के साथ प्रयोग किया जाता है, तो यह डेटाबेस का एक डंप बनाता है जिसमें एक ओप्लॉग शामिल होता है, एक मोंगॉड इंस्टेंस की स्थिति का पॉइंट-इन-टाइम स्नैपशॉट बनाने के लिए। --replayOplog पैरामीटर के साथ mongorestore का उपयोग करके, आप असंगतता से बचने के लिए बैकअप पूर्ण होने पर डेटा स्थिति को पूरी तरह से पुनर्स्थापित कर सकते हैं।

अधिक उन्नत बैकअप आवश्यकताओं के लिए, "mongodbconsistent-backup" नामक एक तृतीय पक्ष टूल - कमांड लाइन आधारित भी - उपलब्ध है जो शार्प किए गए क्लस्टर का पूरी तरह से संगत बैकअप प्रदान करता है, एक जटिल प्रक्रिया, यह देखते हुए कि शार्प किए गए डेटाबेस कई होस्ट में वितरित किए जाते हैं।

निगरानी

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

MongoDB, "mongotop" और "mongostat" के साथ प्रदान किए गए कमांड लाइन टूल आपके परिवेश के प्रदर्शन का विस्तृत दृश्य प्रदान कर सकते हैं, और इसका उपयोग समस्याओं के निदान के लिए किया जा सकता है। इसके अलावा, MongoDB का "मोंगो" कमांड लाइन क्लाइंट "rs.status ()" - या एक शार्प्ड क्लस्टर "sh.status() - में प्रतिकृति सेट या क्लस्टर और उनके सदस्य होस्ट की स्थिति देखने के लिए भी चला सकता है। "db.stats ()" कमांड एक दस्तावेज़ लौटाता है जो भंडारण उपयोग और डेटा वॉल्यूम को संबोधित करता है, और वे संग्रह के लिए समकक्ष हैं, साथ ही साथ कई आंतरिक मीट्रिक तक पहुंचने के लिए अन्य कॉल भी हैं।

सारांश

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

लेकिन आंतरिक टूल और स्क्रिप्ट के बिना, हम MongoDB क्लस्टर को स्वचालित और प्रबंधित कैसे करते हैं? कैसे जानने के लिए श्वेतपत्र डाउनलोड करें!