डेटाबेस सिस्टम की जिम्मेदारी है कि वह किसी भी समय संचालन में जब भी आवश्यक हो, प्रासंगिक डेटा की निरंतर उपलब्धता को संग्रहीत और सुनिश्चित करें। डेटाबेस विफलता, सुरक्षा पुल, मानवीय त्रुटि या विनाशकारी विफलता के परिणामस्वरूप डेटा हानि के मामलों के बाद अधिकांश कंपनियां व्यवसाय जारी रखने में विफल रहती हैं जो उत्पादन में ऑपरेटिंग नोड्स को पूरी तरह से नष्ट कर सकती हैं। डेटाबेस को एक ही डेटा सेंटर में रखने से इन आक्रोशों के मामले में सभी डेटा खोने का उच्च जोखिम होता है।
प्रतिकृति और बैकअप डेटा की उच्च उपलब्धता सुनिश्चित करने के लिए आमतौर पर उपयोग किए जाने वाले तरीके हैं। दोनों के बीच चयन इस बात पर निर्भर करता है कि डेटा कितनी बार बदल रहा है। बैकअप को सबसे अच्छा प्राथमिकता दी जाती है जहां डेटा अधिक बार नहीं बदल रहा है और इतनी सारी बैकअप फ़ाइलें होने की कोई उम्मीद नहीं है। दूसरी ओर, अनुरोधों की विलंबता को कम करके किसी विशिष्ट स्थान पर डेटा की सेवा जैसे जुड़े कुछ अन्य गुणों के अलावा डेटा को बार-बार बदलने के लिए प्रतिकृति को प्राथमिकता दी जाती है। हालाँकि, प्रतिकृति और बैकअप दोनों का उपयोग विफलता के किसी भी मामले में बहाली के दौरान अधिकतम डेटा अखंडता और स्थिरता के लिए किया जा सकता है।
डेटाबेस बैकअप उत्पादन के साथ छेड़छाड़ किए बिना विकास, खुली पहुंच और मंचन के लिए नए वातावरण बनाने के लिए मूल बातें प्रदान करने के लिए बहाली बिंदु प्रदान करने के अलावा अधिक लाभ प्रदान करते हैं। विकास दल नई एकीकृत सुविधाओं का त्वरित और आसानी से परीक्षण कर सकता है और उनके विकास में तेजी ला सकता है। जहां भी परिणामी डेटा संगत नहीं है, वहां कोड त्रुटियों के लिए चेकपॉइंट पर बैकअप का भी उपयोग किया जा सकता है।
MongoDB का बैकअप लेने के लिए विचार
बैकअप कुछ बिंदुओं पर बनाए जाते हैं ताकि यह प्रतिबिंबित किया जा सके (डेटाबेस के स्नैपशॉट के रूप में कार्य करते हुए) डेटाबेस उस समय किस डेटा को होस्ट करता है। यदि डेटाबेस किसी दिए गए बिंदु पर विफल हो जाता है, तो हम डीबी को विफल होने से पहले एक बिंदु पर वापस रोल करने के लिए अंतिम बैकअप फ़ाइल का उपयोग कर सकते हैं। हालांकि, किसी को पुनर्प्राप्ति करने से पहले कुछ कारकों को ध्यान में रखना होगा और उनमें शामिल हैं:
- पुनर्प्राप्ति बिंदु उद्देश्य
- पुनर्प्राप्ति समय उद्देश्य
- डेटाबेस और स्नैपशॉट अलगाव
- साझाकरण के साथ जटिलताएं
- बहाली प्रक्रिया
- प्रदर्शन कारक और उपलब्ध संग्रहण
- लचीलापन
- तैनाती की जटिलता
पुनर्प्राप्ति बिंदु उद्देश्य
ऐसा इसलिए किया जाता है ताकि यह निर्धारित किया जा सके कि बैकअप और बहाली प्रक्रिया के दौरान आप कितना डेटा खोने के लिए तैयार हैं। उदाहरण के लिए, यदि हमारे पास उपयोगकर्ता डेटा और क्लिकस्ट्रीम डेटा है, तो उपयोगकर्ता डेटा को क्लिकस्ट्रीम एनालिटिक्स पर प्राथमिकता दी जाएगी क्योंकि बाद वाले को पुनर्स्थापना के बाद आपके एप्लिकेशन में संचालन की निगरानी करके पुन:उत्पन्न किया जा सकता है। महत्वपूर्ण डेटा जैसे बैंक जानकारी, उत्पादन उद्योग डेटा और संचार प्रणाली की जानकारी के लिए एक निरंतर बैकअप को प्राथमिकता दी जानी चाहिए और इसे निकट अंतराल में किया जाना चाहिए। यदि डेटा बार-बार नहीं बदलता है, तो उदाहरण के लिए 6 महीने या 1 साल पहले का एक पुनर्स्थापित स्नैपशॉट करने पर इसका अधिकांश भाग खोना कम खर्चीला हो सकता है।
पुनर्प्राप्ति समय उद्देश्य
यह विश्लेषण और निर्धारित करने के लिए है कि बहाली का कार्य कितनी जल्दी किया जा सकता है। पुनर्प्राप्ति के दौरान, आपके एप्लिकेशन को कुछ डाउनटाइम लगेगा जो कि पुनर्प्राप्त किए जाने वाले डेटा की मात्रा के सीधे आनुपातिक है। यदि आप डेटा के बड़े सेट को पुनर्स्थापित कर रहे हैं तो इसमें अधिक समय लगेगा।
डेटाबेस और स्नैपशॉट अलगाव
आइसोलेशन इस बात का माप है कि लॉजिकल कॉन्फ़िगरेशन और भौतिक रूप से प्राथमिक डेटाबेस सर्वर से बैकअप स्नैपशॉट कितने करीब हैं। यदि वे काफी करीब होते हैं, तो डेटाबेस के नष्ट होने के साथ ही नष्ट होने की संभावना में वृद्धि की कीमत पर पुनर्प्राप्ति समय कम हो जाता है। बैकअप और उत्पादन वातावरण को एक ही सिस्टम में होस्ट करने की सलाह नहीं दी जाती है ताकि सर्वर पर बैकअप में भी कम होने से किसी भी व्यवधान से बचा जा सके।
साझाकरण के साथ जटिलताएं
शार्डिंग के माध्यम से एक वितरित डेटाबेस सिस्टम के लिए, कुछ बैकअप जटिलता प्रस्तुत की जाती है और पूरे सिस्टम में लेखन गतिविधियों को रोकना पड़ सकता है। अलग-अलग शार्क अलग-अलग समय पर अलग-अलग तरह के बैकअप खत्म करेंगे। तार्किक बैकअप और स्नैपशॉट बैकअप को ध्यान में रखते हुए,
तार्किक बैकअप
- शार्ड अलग-अलग आकार के होते हैं इसलिए अलग-अलग समय पर खत्म हो जाएंगे
- MongoDB-बेस डंप --oplog को नज़रअंदाज़ कर देगा, इसलिए प्रत्येक शार्क पर संगत नहीं होगा।
- बैलेंसर बंद हो सकता है जबकि इसे चालू होना चाहिए क्योंकि कुछ शार्क ने शायद बहाली प्रक्रिया पूरी नहीं की है
स्नैपशॉट बैकअप
- संस्करण 3.2 और बाद के संस्करणों से एकल प्रतिकृति के लिए अच्छी तरह से काम करता है। इसलिए, आपको अपने MongoDB संस्करण को अपडेट करने पर विचार करना चाहिए।
बहाली प्रक्रिया
कुछ लोग परीक्षण के बिना बैकअप लेते हैं यदि वे बहाली के मामले में काम करेंगे। संक्षेप में एक बैकअप एक बहाली क्षमता प्रदान करना है अन्यथा यह बेकार हो जाएगा। यह देखने के लिए कि क्या वे काम कर रहे हैं, आपको हमेशा विभिन्न परीक्षण सर्वरों पर बैकअप चलाने का प्रयास करना चाहिए।
प्रदर्शन कारक और उपलब्ध संग्रहण
बैकअप भी डेटाबेस से डेटा के रूप में कई आकार लेते हैं और उन्हें पर्याप्त रूप से संपीड़ित करने की आवश्यकता होती है ताकि बहुत अधिक अनावश्यक स्थान पर कब्जा न हो जो सिस्टम के समग्र भंडारण संसाधनों को काट सकता है। उन्हें ज़िप फ़ाइलों में संग्रहीत किया जा सकता है इसलिए उनके समग्र आकार को कम किया जा सकता है। इसके अलावा, जैसा कि पहले उल्लेख किया गया है, कोई भी डेटाबेस से ही विभिन्न डेटासेंटर में बैकअप संग्रहीत कर सकता है।
बैकअप डेटाबेस के विभिन्न प्रदर्शनों को निर्धारित कर सकता है जिसमें कुछ इसे नीचा दिखा सकते हैं। उस स्थिति में, निरंतर बैकअप कुछ झटका प्रदान करेगा इसलिए रखरखाव विंडो की कमी से बचने के लिए अनुसूचित बैकअप में परिवर्तित किया जाना चाहिए। ज्यादातर मामलों में, बैकअप का समर्थन करने के लिए द्वितीयक सर्वर तैनात किए जाते हैं। इस मामले में:
- एकल नोड्स का लगातार बैकअप नहीं लिया जा सकता क्योंकि MongoDB mongodump कमांड का उपयोग करते समय बिना किसी oplog के रीड-अनकमिटेड का उपयोग करता है और उस स्थिति में बैकअप सुरक्षित नहीं होगा।
- बैकअप के लिए सेकेंडरी नोड्स का उपयोग करें क्योंकि प्रक्रिया में शामिल डेटा की मात्रा के अनुसार समय लगता है और जुड़े हुए एप्लिकेशन में कुछ डाउनटाइम लगेगा। यदि आप प्राथमिक का उपयोग करते हैं जिसे Oplogs को भी अपडेट करना है, तो आप उस डाउनटाइम के दौरान कुछ डेटा खो सकते हैं
- पुनर्स्थापित करने की प्रक्रिया में बहुत समय लगता है लेकिन आवंटित भंडारण संसाधन छोटे होते हैं।
लचीलापन
कई बार आप बैकअप के दौरान कुछ डेटा नहीं चाहते हैं, जैसा कि पुनर्प्राप्ति बिंदु उद्देश्य के उदाहरण के लिए, कोई व्यक्ति पुनर्प्राप्ति करना चाहता है और उपयोगकर्ता क्लिक डेटा को फ़िल्टर कर सकता है। ऐसा करने के लिए, आपको एक आंशिक बैकअप रणनीति की आवश्यकता है जो उस डेटा को फ़िल्टर करने के लिए लचीलापन प्रदान करेगी जिसमें आपकी रुचि नहीं होगी, इसलिए पुनर्प्राप्ति अवधि और बर्बाद होने वाले संसाधनों को कम करें। इंक्रीमेंटल बैकअप भी उपयोगी हो सकता है ताकि हर स्नैपशॉट के लिए संपूर्ण बैकअप लेने के बजाय केवल डेटा भाग जो बदल गए हैं, अंतिम स्नैपशॉट से बैकअप किए जाएंगे।
तैनाती की जटिलता
आपकी बैकअप रणनीति को समय के साथ सेट करना और बनाए रखना आसान होना चाहिए। आप अपने बैकअप को शेड्यूल भी कर सकते हैं ताकि जब भी आप चाहें उन्हें मैन्युअल रूप से करने की आवश्यकता न हो।
निष्कर्ष
डेटाबेस सिस्टम "मृत्यु के बाद के जीवन" की गारंटी देता है यदि केवल अच्छी तरह से स्थापित बैकअप सिस्टम है। डेटाबेस को विनाशकारी कारकों, मानवीय त्रुटि या सुरक्षा हमलों से नष्ट किया जा सकता है जिससे डेटा की हानि या भ्रष्टाचार हो सकता है। बैकअप करने से पहले, आकार और महत्व के संदर्भ में डेटा के प्रकार पर विचार करना होगा। अपने बैकअप को अपने डेटाबेस के समान डेटा सेंटर में रखना हमेशा उचित नहीं है ताकि बैकअप के एक साथ नष्ट होने की संभावना को कम किया जा सके। बैकअप डेटाबेस के प्रदर्शन को बदल सकते हैं इसलिए किसी को उपयोग करने की रणनीति और बैकअप कब करना है, इसके बारे में सावधान रहना चाहिए। अपने बैकअप को प्राथमिक नोड पर न करें क्योंकि इसके परिणामस्वरूप बैकअप के दौरान सिस्टम डाउनटाइम हो सकता है और परिणामस्वरूप महत्वपूर्ण डेटा की हानि हो सकती है।
