MongoDB के लिए सामान्य विफलता परिदृश्यों को ठीक करने के लिए बैकअप का उपयोग करना

उत्पादन में किसी भी समय रुकावट होने की लगभग गारंटी है। इस तथ्य को स्वीकार करना और अपने डेटाबेस आउटेज की समयरेखा और विफलता परिदृश्य का विश्लेषण करना अगले एक से बेहतर तैयारी, निदान और पुनर्प्राप्त करने में मदद कर सकता है। डाउनटाइम के प्रभाव को कम करने के लिए, संगठनों को एक उपयुक्त आपदा वसूली (डीआर) योजना की आवश्यकता है। कई SysOps/DevOps के लिए DR नियोजन एक महत्वपूर्ण कार्य है, लेकिन भले ही यह पूर्वाभास हो; अक्सर यह मौजूद नहीं होता है।

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

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

MongoDB डेटा को कैसे स्टोर करता है

MongoDB एक दस्तावेज़-उन्मुख डेटाबेस है। अपने डेटा को अलग-अलग पंक्तियों से बनी तालिकाओं में संग्रहीत करने के बजाय (जैसा कि एक रिलेशनल डेटाबेस करता है), यह डेटा को अलग-अलग दस्तावेज़ों से बने संग्रह में संग्रहीत करता है। MongoDB में, एक दस्तावेज़ एक बड़ा JSON बूँद है जिसमें कोई विशेष प्रारूप या स्कीमा नहीं है। इसके अतिरिक्त, डेटा को अलग-अलग क्लस्टर नोड्स में साझा करने के साथ फैलाया जा सकता है या रेप्लिकासेट के साथ स्लेव सर्वर पर दोहराया जा सकता है।

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

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

डिस्क-स्तरीय डेटा भ्रष्टाचार या अनुपलब्ध डेटा फ़ाइलें mongod उदाहरणों को प्रारंभ होने से रोक सकती हैं, और जर्नल फ़ाइलें स्वचालित रूप से पुनर्प्राप्त करने के लिए अपर्याप्त हो सकती हैं।

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

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

MongoDB आपदा पुनर्प्राप्ति परिदृश्य

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

आरपीओ का अनुमान लगाने के लिए आपको खुद से कुछ सवाल पूछने होंगे। मेरे डेटा का बैकअप कब लिया जाता है? डेटा की पुनर्प्राप्ति से संबंधित SLA क्या है? क्या डेटा का बैकअप बहाल करना स्वीकार्य है या क्या डेटा को ऑनलाइन होना चाहिए और किसी भी समय पूछताछ के लिए तैयार होना चाहिए?

इन सवालों के जवाब आपको किस प्रकार के बैकअप समाधान की जरूरत है, यह ड्राइव करने में मदद करेंगे।

MongoDB बैकअप समाधान

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

आपके MongoDB सर्वर/क्लस्टर का बैकअप लेने के तीन सबसे सामान्य समाधान हैं...

• मोंगोडम्प/मोंगोरेस्टोर - तार्किक बैकअप।
• मोंगो प्रबंधन प्रणाली (क्लाउड) - उत्पादन डेटाबेस का बैकअप मोंगोडीबी ऑप्स मैनेजर का उपयोग करके किया जा सकता है या यदि मोंगोडीबी एटलस सेवा का उपयोग कर रहे हैं तो आप पूरी तरह से प्रबंधित बैकअप समाधान का उपयोग कर सकते हैं।
• डेटाबेस स्नैपशॉट (डिस्क-स्तरीय बैकअप)

मोंगोडम्प/मोंगोरेस्टोर

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

डिफ़ॉल्ट रूप से, mongodump डंप नामक एक निर्देशिका बनाएगा, जिसमें प्रत्येक डेटाबेस के लिए एक निर्देशिका होगी जिसमें उस डेटाबेस में प्रति संग्रह एक BSON फ़ाइल होगी। वैकल्पिक रूप से, आप mongodump को बैकअप को एक एकल संग्रह फ़ाइल में संग्रहीत करने के लिए कह सकते हैं। संग्रह पैरामीटर सभी डेटाबेस और संग्रह से आउटपुट को बाइनरी डेटा की एक एकल स्ट्रीम में जोड़ देगा। इसके अतिरिक्त, gzip पैरामीटर gzip का उपयोग करके इस संग्रह को स्वाभाविक रूप से संपीड़ित कर सकता है। ClusterControl में हम अपने सभी बैकअप को स्ट्रीम करते हैं, इसलिए हम आर्काइव और gzip पैरामीटर दोनों को सक्षम करते हैं।

MySQL के साथ mysqldump के समान, यदि आप MongoDB में बैकअप बनाते हैं तो यह बैकअप फ़ाइल में सामग्री को डंप करते समय संग्रह को फ्रीज कर देगा। चूंकि MongoDB लेन-देन का समर्थन नहीं करता है (4.2 में बदला गया) आप 100% पूरी तरह से सुसंगत बैकअप नहीं बना सकते जब तक कि आप oplog पैरामीटर के साथ बैकअप नहीं बनाते। बैकअप पर इसे सक्षम करने में oplog से लेन-देन शामिल हैं जो बैकअप बनाते समय निष्पादित कर रहे थे।

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

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

एक बैकअप से MongoDB को पुनर्स्थापित करना

बीएसओएन प्रारूप डंप का उपयोग करने के मूल रूप से दो तरीके हैं:

1. मोंगॉड को सीधे बैकअप निर्देशिका से चलाएं
2. mongorestore चलाएँ और बैकअप पुनर्स्थापित करें

मोंगॉड को सीधे बैकअप से चलाएं

मोंगॉड को सीधे बैकअप से चलाने के लिए एक शर्त यह है कि बैकअप लक्ष्य एक मानक डंप है, और gzipped नहीं है।

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

मोंगोरेस्टोर चल रहा है

पुनर्स्थापित करने का एक बेहतर तरीका स्पष्ट रूप से एक mongorestore का उपयोग करके नोड को पुनर्स्थापित करना होगा।

mongorestore  dump/

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

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

ऑब्जेक्ट सत्यापन

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

उस उपयोग को संबोधित करने के लिए -- objcheck जो mongorestore को प्राप्ति पर ग्राहकों से सभी अनुरोधों को मान्य करने के लिए बाध्य करता है ताकि यह सुनिश्चित हो सके कि ग्राहक डेटाबेस में कभी भी अमान्य दस्तावेज़ सम्मिलित नहीं करते हैं। इसका प्रदर्शन पर थोड़ा प्रभाव पड़ सकता है।

ओप्लॉग रीप्ले

आपके बैकअप का विरोध आपको लगातार बैकअप करने और पॉइंट-इन-टाइम-रिकवरी करने में सक्षम करेगा। पुनर्स्थापना प्रक्रिया के दौरान oplog लागू करने के लिए oplogReplay पैरामीटर सक्षम करें। यह नियंत्रित करने के लिए कि ओप्लॉग को कितनी दूर तक चलाया जाए, आप oplogLimit पैरामीटर में टाइमस्टैम्प को परिभाषित कर सकते हैं। केवल टाइमस्टैम्प तक के लेन-देन तब लागू होंगे।

बैकअप से एक पूर्ण प्रतिकृति सेट को पुनर्स्थापित करना

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

पहले नोड को पुनर्स्थापित करें, फिर रेप्लिकासेट बनाएं

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

पहले एक रेप्लिकासेट बनाएं, फिर पुनर्स्थापित करें

पिछली प्रक्रिया से अलग, आप पहले रेप्लिकासेट बना सकते हैं। सबसे पहले सभी तीन होस्ट को रेप्लिकासेट सक्षम के साथ कॉन्फ़िगर करें, सभी तीन डेमॉन को स्टार्ट-अप करें और पहले नोड पर रेप्लिकासेट शुरू करें:

अब जब हमने रेप्लिकासेट बना लिया है, तो हम इसमें सीधे अपने बैकअप को पुनर्स्थापित कर सकते हैं:

हमारी राय में, इस तरह से एक रेप्लिकासेट को पुनर्स्थापित करना कहीं अधिक सुंदर है। यह उस तरह से करीब है जिस तरह से आप सामान्य रूप से एक नया प्रतिकृति सेट करते हैं, और फिर इसे (उत्पादन) डेटा से भरते हैं।

रेप्लिकासेट में एक नया नोड सीडिंग करना

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

बैकअप के साथ सीडिंग

तो क्या होगा यदि आप इसके बजाय एक mongodump बैकअप से नए नोड को पुनर्स्थापित करते हैं, और फिर इसे एक रेप्लिकासेट में शामिल कर लेते हैं? एक बैकअप से पुनर्स्थापित करना, सिद्धांत रूप में, समान डेटासेट देना चाहिए। चूंकि इस नए नोड को बैकअप से पुनर्स्थापित किया गया है, इसमें प्रतिकृतिसेटआईड की कमी होगी और मोंगोडीबी नोटिस करेगा। चूंकि MongoDB इस नोड को रेप्लिकासेट के हिस्से के रूप में नहीं देखता है, rs.add () कमांड तब हमेशा MongoDB प्रारंभिक सिंक को ट्रिगर करेगा। प्रारंभिक सिंक हमेशा MongoDB नोड पर मौजूद किसी भी मौजूदा डेटा को हटाने को ट्रिगर करेगा।

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