MongoDB के लिए एक विकास और संचालन चेकलिस्ट

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

1. स्कीमा डिज़ाइन
2. डेटा टिकाऊपन
3. प्रतिकृति
4. डिस्क 
5. साझा करना 

दूसरी ओर, एक ऑपरेशन चेकलिस्ट, पते...

1. प्रतिकृति
2. फाइल सिस्टम 
3. साझा करना
4. हार्डवेयर
5. जर्नलिंग (वायर्ड टाइगर स्टोरेज इंजन) 
6. ऑपरेटिंग सिस्टम कॉन्फ़िगरेशन 
7. क्लाउड हार्डवेयर में परिनियोजन 
8. निगरानी
9. बैकअप और लोड बैलेंसिंग

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

MongoDB ऑपरेशंस चेकलिस्ट

प्रतिकृति

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

ऑप्लॉग आकार को परिचालन संबंधी जरूरतों को पूरा करने के लिए ठीक से कॉन्फ़िगर किया जाना चाहिए जैसे:

• पूर्ण resync की आवश्यकता से बचने के लिए, प्रतिकृति oplog एप्लिकेशन विंडो को नियमित डाउनटाइम और रखरखाव विंडो को कवर करना चाहिए।
• प्रतिकृति सेट सदस्य को पुनर्स्थापित करने के लिए, प्रतिकृति oplog विंडो को हमेशा आवश्यक समय को कवर करना चाहिए।

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

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

आईपी पते का उपयोग करने के बजाय, जिसके लिए आईपी बदलने के कारण कॉन्फ़िगरेशन बदलने की आवश्यकता हो सकती है, तार्किक डीएनएस होस्टनाम के उपयोग की सिफारिश की जाती है।

सुनिश्चित करें कि mongod उदाहरणों में 0 या 1 वोट हैं।

सभी Mongod इंस्टेंसेस को पूरी तरह से और द्विदिश रूप से जोड़ा जाना चाहिए ताकि शामिल नोड्स के बीच डेटा के संचार में आसानी हो।

जर्नलिंग

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

हालांकि, ध्यान रखें कि यह स्नैपशॉट-शैली के सुदृढीकरण को प्रभावित करता है क्योंकि डेटाबेस की स्थिति का गठन करने वाले रिकॉर्ड विभाजित वॉल्यूम पर रहेंगे।

फाइल सिस्टम

डीबीपाथ के लिए न्यूज फाइल सिस्टम (एनएफएस) ड्राइव का प्रयोग न करें। NFS ड्राइव के परिणामस्वरूप संभवतः अस्थिर प्रदर्शन हो सकता है। VMware उपयोगकर्ताओं द्वारा उपयोग के लिए VMware वर्चुअल ड्राइव की अनुशंसा की जाती है।

सुनिश्चित करें कि आपके डिस्क विभाजन आपके RAIDON कॉन्फ़िगरेशन के साथ संरेखित हैं।

लिनक्स/यूनिक्स उपयोगकर्ताओं के लिए, XFS के उपयोग की अनुशंसा की जाती है। XFS को MongoDB के साथ बेहतर प्रदर्शन करने के लिए जाना जाता है।

विंडोज़ ऑपरेटिंग सिस्टम उपयोगकर्ताओं के लिए, NTFS फ़ाइल सिस्टम की अनुशंसा की जाती है। आपको किसी भी FAT फाइल सिस्टम का उपयोग करने से बचना चाहिए।

क्लाउड हार्डवेयर में परिनियोजन

Windows Azure:TCP कीपलाइव (tcp_keepalive_time) को 100-120 में बदलें। Azure स्टैक बैलेंसर पर TCP सिट आउट ऑफ़ गियर टाइमआउट, MongoDB के संबद्धता पूलिंग व्यवहार के लिए उतना ही मध्यम है

मोंगोडीबी 2.6.4 या उच्च-विलंबता भंडारण वाले ढांचे पर नए संस्करणों का उपयोग करें, जैसे कि विंडोज़ एज़ूर, क्योंकि इन संस्करणों में उन ढांचे के लिए निष्पादन संवर्द्धन शामिल हैं।

शेयरिंग

विस्तृत क्लस्टर में आदर्श निष्पादन के लिए अपने कॉन्फ़िगरेशन सर्वर को समर्पित हार्डवेयर पर रखें।

सुनिश्चित करें कि हार्डवेयर में सूचना रिकॉर्ड को पूरी तरह से मेमोरी में रखने के लिए पर्याप्त रैम है और इसमें स्टोरेज समर्पित है।

जनरेशन सेटअप दिशानिर्देशों के अनुरूप mongos राउटर्स को परिनियोजित करें।

NTP का उपयोग करके अपने शार्प किए गए क्लस्टर के सभी घटकों पर घड़ियों को सिंक्रनाइज़ करें।

मोंगोस, मोंगोड और कॉन्फिग सर्वर के बीच पूर्ण द्विदिश नेटवर्क सुनिश्चित करें।

क्लस्टर में अपने कॉन्फिग सर्वर को पहचानने के लिए CNAME का उपयोग करें ताकि आप बिना डाउनटाइम के अपने कॉन्फिग सर्वर का नाम बदल सकें और उनका नंबर बदल सकें।

निगरानी

आप प्रमुख डेटाबेस मेट्रिक्स को स्क्रीन करने और अलार्म सेट करने के लिए MongoDB क्लाउड मैनेजर, ClusterControl, या किसी अन्य मॉनिटरिंग फ्रेमवर्क जैसे टूल का उपयोग कर सकते हैं। मेट्रिक्स के लिए अलर्ट शामिल करें:

• कतार
• प्रतिकृति oplog विंडो
• अभिकथन
• पेज दोष
• प्रतिकृति अंतराल

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

हार्डवेयर

आदर्श प्रदर्शन के लिए RAID10 और SSD ड्राइव का उपयोग करें।

सैन और वर्चुअलाइजेशन:

सुनिश्चित करें कि प्रत्येक मोंगॉड इंस्टेंस ने अपने dbPath के लिए IOPS का प्रावधान किया है, या उसका दावा भौतिक ड्राइव या LUN है।

वर्चुअल वातावरण में चलते समय डायनामिक मेमोरी हाइलाइट, जैसे मेमोरी सूजन, से बचें।

सभी कॉपी सेट व्यक्तियों को एक ही SAN पर सेट करने से बचें, क्योंकि SAN निराशा का एक बिंदु हो सकता है।

लोड संतुलन

मौजूदा कनेक्शन के लिए पर्याप्त टाइमआउट के साथ "स्टिकी सेशन" या "क्लाइंट एफ़िनिटी" को सक्षम करने के लिए लोड बैलेंसर्स डिज़ाइन करें।

मोंगोडीबी क्लस्टर या प्रतिकृति सेट घटकों के बीच लोड बैलेंसर डालने से बचें।

बैकअप

अपने बैकअप के लिए रुक-रुक कर परीक्षण की योजना बनाएं और समय मापने की प्रक्रिया को बहाल करें और इसकी उपयोगिता की पुष्टि करें।

ऑपरेटिंग सिस्टम कॉन्फ़िगरेशन

विंडोज

एनटीएफएस "अंतिम पहुंच समय" अपग्रेड को निष्क्रिय करने पर विचार करें।

4096 बाइट्स के डिफ़ॉल्ट आवंटन इकाई आकार का उपयोग करके NTFS डिस्क को प्रारूपित करें।

लिनक्स

विशाल पारदर्शी पृष्ठों को बंद करें।

पांसे की रीडहेड सेटिंग में समायोजन करें जहां आपकी डेटाबेस फ़ाइलें संग्रहीत हैं। WiredTiger स्टोरेज इंजन का रीडहेड 8 और 32 के बीच सेट किया जाना चाहिए।

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

सीधे विशाल पृष्ठों को अक्षम करें।

किसी भी मामले में क्षमता मीडिया सॉर्टिंग के मामले में रीडहेड को 8 और 32 के बीच सेट करें।

SSD ड्राइव के लिए नोप या डेडलाइन डिस्क शेड्यूलर का उपयोग करें।

अतिथि VMs में वर्चुअलाइज्ड ड्राइव के लिए noop डिस्क शेड्यूलर का उपयोग करें।

NUMA अक्षम करें या vm.zone_reclaim_mode को 0 पर सेट करें और नोड इंटरलीविंग के साथ mongod आवृत्तियों को चलाएं।

अपने उपयोग के मामले से मेल खाने के लिए अपने हार्डवेयर पर ulimit मानों को समायोजित करें। इस घटना में कि एक ही क्लाइंट के नीचे अलग-अलग मोंगोड या मोंगोस घटनाएं चल रही हैं, इसी तरह से यूलिमिट वैल्यू को स्केल करें।

पर्याप्त रिकॉर्ड हैंडल (fs.file-max), पार्ट पिड बाधा (kernel.pid_max), अधिकतम थ्रेड प्रति प्रक्रिया (kernel.threads-max), और प्रति प्रक्रिया मेमोरी आउटलाइन क्षेत्रों की अधिकतम संख्या डिज़ाइन करें (vm.max_map_count) आपके भेजने के लिए। विस्तृत ढांचे के लिए, निम्नलिखित मान एक अच्छी शुरुआत देते हैं:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

सुनिश्चित करें कि आपके ढांचे में स्वैप स्थान कॉन्फ़िगर किया गया है।

सही आकार पर रुचि के बिंदुओं के लिए अपने ऑपरेटिंग सिस्टम के दस्तावेज़ीकरण का संकेत दें।

 सुनिश्चित करें कि सिस्टम डिफ़ॉल्ट TCP Keepalive सटीक रूप से सेट है। 300 का मान अक्सर प्रतिकृति सेट और शार्प किए गए क्लस्टर के लिए बेहतर प्रदर्शन देता है।

MongoDB डेवलपमेंट चेकलिस्ट

प्रतिकृति

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

गारंटी है कि आपके सेकेंडरी मॉनिटरिंग टूल का उपयोग करके और उपयुक्त लेखन चिंता का संकेत देकर अप-टू-डेट रहें।

पूरे पठन थ्रूपुट को मापने के लिए सहायक पठन का उपयोग न करें।

स्कीमा डिज़ाइन

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

संग्रहों का वह सेट तय करें जिसकी आपको बस आवश्यकता होगी और आपके प्रश्नों का समर्थन करने के लिए आवश्यक अनुक्रमणिका। _id अनुक्रमणिका के विशेष मामले के साथ, आपको सभी अनुक्रमणिका स्पष्ट रूप से बनानी चाहिए:MongoDB स्वाभाविक रूप से _id के अलावा कोई अनुक्रमणिका नहीं बनाता है।

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

सुनिश्चित करें कि आपकी स्कीमा योजना अनुक्रमित समूहों पर निर्भर नहीं है जो बिना सीमा के लंबाई में बढ़ते हैं। आमतौर पर, सबसे अच्छा निष्पादन तब पूरा किया जा सकता है जब ऐसे अनुक्रमित समूहों में 1000 से कम घटक हों।

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

ड्राइवर

एसोसिएशन पूलिंग का उपयोग करें। अधिकांश MongoDB ड्राइवर एसोसिएशन पूलिंग का समर्थन करते हैं। समवर्ती डेटाबेस मांगों की सामान्य संख्या के 110-115% से शुरू करके, अपने उपयोग के मामले के अनुरूप एसोसिएशन पूल आकार बदलें।

सुनिश्चित करें कि आपके एप्लिकेशन प्रतिकृति सेट चुनावों के दौरान अस्थायी लिखने और पढ़ने की गलतियों को संभालते हैं।

गारंटी है कि आपके एप्लिकेशन विफल अनुरोधों को संभालते हैं और यदि उपयुक्त हो तो उन्हें पुनः प्रयास करें। ड्राइवर नहीं

स्वाभाविक रूप से विफल अनुरोधों का पुन:प्रयास करें।

डेटाबेस अनुरोध पुन:प्रयास के लिए घातीय बैकऑफ तर्क का उपयोग करें।

यदि आप डेटाबेस संचालन के लिए निष्पादन अवधि को सीमित करना चाहते हैं तो पढ़ने और लिखने के लिए समय समाप्त करने के लिए कर्सर.मैक्सटाइमएमएस() का उपयोग करें।

डेटा टिकाऊपन

सुनिश्चित करें कि आपके प्रतिकृति सेट में कम से कम तीन डेटा-असर वाले हब शामिल हैं जिनमें w:अधिकांश कंपोज़ चिंता है। प्रतिकृति-सेट विस्तृत डेटा सॉलिडनेस के लिए तीन डेटा-असर हब की आवश्यकता होती है।

गारंटी है कि सभी उदाहरण जर्नलिंग का उपयोग करते हैं।

शेयरिंग

गारंटी है कि आपकी शार्ड कुंजी आपके शार्क पर समान रूप से भार पहुंचाती है।

उन कार्यभार के लिए लक्षित संचालन का उपयोग करें जो शार्क की संख्या के साथ बड़े पैमाने पर हो गए हैं।

MongoDB 3.6 और उसके बाद के लिए, सेकेंडरी अब अनाथ डेटा नहीं लौटाते हैं जब तक कि "उपलब्ध" रीड चिंता का उपयोग नहीं किया जाता है (जो कि अत्यधिक विश्वसनीय सत्रों से संबंधित नहीं होने पर सेकेंडरी के खिलाफ रीड के लिए डिफ़ॉल्ट रीड चिंता है)।

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

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

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

निष्कर्ष 

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