कॉन्फ़िगर सर्वर प्रोटोकॉल
MongoDB 3.0 और पहले वाला केवल एक ही प्रकार के कॉन्फिगर सर्वर परिनियोजन प्रोटोकॉल का समर्थन करता है जिसे MongoDB 3.2 के रूप में लीगेसी SCCC (सिंक क्लस्टर कनेक्शन कॉन्फ़िगरेशन) के रूप में संदर्भित किया जाता है। एक SCCC परिनियोजन में या तो 1 कॉन्फ़िग सर्वर (केवल विकास) या 3 कॉन्फ़िग सर्वर (उत्पादन) होते हैं।
MongoDB 3.2 SCCC प्रोटोकॉल को हटा देता है और एक नए परिनियोजन प्रकार का समर्थन करता है:कॉन्फ़िगरेशन सर्वर प्रतिकृति सेट (CSRS) के रूप में। एक CSRS परिनियोजन में मानक प्रतिकृति सेट के समान सीमाएँ होती हैं, जिसमें MongoDB 3.2 की तरह 1 कॉन्फ़िग सर्वर (केवल विकास) या 50 सर्वर (उत्पादन) तक हो सकता है। उत्पादन परिनियोजन में उच्च उपलब्धता के लिए न्यूनतम 3 CSRS सर्वरों की अनुशंसा की जाती है, लेकिन अतिरिक्त सर्वर भौगोलिक रूप से वितरित परिनियोजन के लिए उपयोगी हो सकते हैं।
SCCC (सिंक क्लस्टर कनेक्शन कॉन्फ़िगरेशन)
SCCC के साथ, कॉन्फिग सर्वरों को एक दो-चरण प्रतिबद्धता का उपयोग करके अपडेट किया जाता है। प्रोटोकॉल जिसमें लेनदेन के लिए कई सर्वरों से आम सहमति की आवश्यकता होती है। आप परीक्षण/विकास उद्देश्यों के लिए एकल कॉन्फ़िगरेशन सर्वर का उपयोग कर सकते हैं, लेकिन उत्पादन के उपयोग में आपके पास हमेशा 3 होना चाहिए। MongoDB में आप केवल 2 (या 3 से अधिक) सर्वर का उपयोग क्यों नहीं कर सकते, इसका एक व्यावहारिक उत्तर यह है कि MongoDB कोड आधार केवल SCCC कॉन्फ़िगरेशन के लिए 1 या 3 कॉन्फ़िग सर्वर का समर्थन करता है।
तीन सर्वर दो सर्वरों की तुलना में निरंतरता की एक मजबूत गारंटी प्रदान करते हैं, और एक कॉन्फिग सर्वर पर रखरखाव गतिविधि (उदाहरण के लिए, बैकअप) की अनुमति देते हैं, जबकि आपके mongos के लिए अभी भी दो सर्वर उपलब्ध हैं। पूछताछ करने के लिए। तीन से अधिक सर्वर सभी सर्वरों पर डेटा जमा करने में लगने वाले समय को बढ़ा देंगे।
आपके शार्प किए गए क्लस्टर के लिए मेटाडेटा को सभी कॉन्फ़िगरेशन सर्वरों में समान होना चाहिए, और इसे MongoDB शार्डिंग कार्यान्वयन द्वारा बनाए रखा जाता है। मेटाडेटा में आवश्यक विवरण शामिल होते हैं, जिनमें से शार्क वर्तमान में दस्तावेज़ों की श्रेणी रखते हैं (उर्फ chunks ) SCCC कॉन्फ़िगरेशन में, कॉन्फ़िग सर्वर नहीं होते हैं एक प्रतिकृति सेट, इसलिए यदि एक या अधिक कॉन्फ़िगरेशन सर्वर ऑफ़लाइन हैं तो कॉन्फ़िगरेशन डेटा केवल पढ़ा जाएगा - अन्यथा डेटा के ऑफ़लाइन कॉन्फ़िगरेशन सर्वर पर वापस ऑनलाइन होने पर प्रचार करने का कोई साधन नहीं है।
स्पष्ट रूप से 1 कॉन्फ़िगरेशन सर्वर कोई अतिरेक या बैकअप प्रदान नहीं करता है। 2 कॉन्फ़िगरेशन सर्वरों के साथ, एक संभावित विफलता परिदृश्य वह होता है जहां सर्वर उपलब्ध होते हैं लेकिन सर्वर पर डेटा सहमत नहीं होता है (उदाहरण के लिए, सर्वरों में से एक में कुछ डेटा भ्रष्टाचार था)। 3 कॉन्फ़िगरेशन सर्वर के साथ आप पिछले परिदृश्य में सुधार कर सकते हैं:2/3 सर्वर सुसंगत हो सकते हैं और आप अजीब सर्वर की पहचान कर सकते हैं।
CSRS (प्रतिकृति सेट के रूप में सर्वर कॉन्फ़िगर करें)
MongoDB 3.2 तीन प्रतिबिम्बित mongod . के उपयोग की अवहेलना करता है कॉन्फ़िगरेशन सर्वर के लिए इंस्टेंस, और 3.2 कॉन्फ़िगरेशन सर्वर में प्रारंभ (डिफ़ॉल्ट रूप से) प्रतिकृति सेट के रूप में तैनात किया जाता है। रेप्लिका सेट कॉन्फ़िगरेशन सर्वर को WiredTiger 3.2+ स्टोरेज इंजन (या कोई अन्य स्टोरेज इंजन जो नए readConcern
अलगाव शब्दार्थ पढ़ें)। CSRS कुछ गैर-डिफ़ॉल्ट प्रतिकृति सेट कॉन्फ़िगरेशन विकल्पों को भी अस्वीकार करता है (उदा. arbiterOnly , buildIndexes , और slaveDelay ) जो शार्प किए गए क्लस्टर मेटाडेटा उपयोग के मामले के लिए अनुपयुक्त हैं।
CSRS परिनियोजन कॉन्फ़िगरेशन सर्वर के लिए स्थिरता और उपलब्धता में सुधार करता है, क्योंकि MongoDB कॉन्फ़िगरेशन डेटा को साझा करने के लिए मानक प्रतिकृति सेट पढ़ने और लिखने के प्रोटोकॉल का लाभ उठा सकता है। इसके अलावा, यह एक शार्प किए गए क्लस्टर को 3 से अधिक कॉन्फ़िगरेशन सर्वर रखने की अनुमति देता है क्योंकि एक प्रतिकृति सेट में अधिकतम 50 सदस्य हो सकते हैं (जैसे कि MongoDB 3.2)।
CSRS परिनियोजन के साथ, लेखन उपलब्धता सदस्यों के कोरम को बनाए रखने पर निर्भर करती है जो प्रतिकृति सेट के लिए वर्तमान प्राथमिक देख सकते हैं। उदाहरण के लिए, एक 3-नोड प्रतिकृति सेट को प्राथमिक बनाए रखने के लिए 2 उपलब्ध सदस्यों की आवश्यकता होगी। बेहतर गलती सहनशीलता<के लिए अतिरिक्त सदस्यों को जोड़ा जा सकता है /ए> , उसी चुनाव नियमों
के अधीन एक सामान्य प्रतिकृति सेट के रूप में। एक readConcern majority . का mongos . द्वारा उपयोग किया जाता है यह सुनिश्चित करने के लिए कि शार्प किए गए क्लस्टर मेटाडेटा को केवल एक बार पढ़ा जा सकता है जब यह अधिकांश प्रतिकृति सेट सदस्यों और readPreference के लिए प्रतिबद्ध हो nearest . का अनुरोधों को निकटतम कॉन्फ़िगरेशन सर्वर पर रूट करने के लिए उपयोग किया जाता है।
