डेटाबेस बैकअप के लिए सर्वोत्तम अभ्यास

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

हम देखेंगे कि कैसे क्लस्टरकंट्रोल आपको MySQL, MariaDB, MongoDB और PostgreSQL के लिए केंद्रीकृत बैकअप प्रबंधन प्रदान करता है। यह आपको बड़े डेटासेट का हॉट बैकअप, पॉइंट इन टाइम रिकवरी, एट-रेस्ट और इन-ट्रांजिट डेटा एन्क्रिप्शन, स्वचालित पुनर्स्थापना सत्यापन के माध्यम से डेटा अखंडता, डिजास्टर रिकवरी के लिए क्लाउड बैकअप (AWS, Google और Azure), अनुपालन सुनिश्चित करने के लिए अवधारण नीतियां प्रदान करता है। , और स्वचालित अलर्ट और रिपोर्टिंग।

बैकअप प्रकार

दो मुख्य प्रकार के बैकअप हैं जो हम ClusterControl में कर सकते हैं:

• लॉजिकल बैकअप - डेटा का बैकअप SQL जैसे मानव-पठनीय प्रारूप में संग्रहीत किया जाता है
• भौतिक बैकअप - बैकअप में बाइनरी डेटा होता है

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

ClusterControl MySQL/MariaDB/Percona Server, PostgreSQL, और MongoDB के लिए बैकअप का समर्थन करता है।

शेड्यूल बैकअप

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

उपलब्ध अनुसूचित बैकअप अनुसूचित बैकअप टैब में सूचीबद्ध होंगे जैसा कि नीचे दी गई छवि में देखा गया है:

बैकअप शेड्यूल करने के लिए एक अच्छे अभ्यास के रूप में, आपके पास पहले से ही अपना परिभाषित बैकअप प्रतिधारण होना चाहिए और एक दैनिक बैकअप की अनुशंसा की जाती है। हालाँकि, यह आपके द्वारा आवश्यक डेटा, आपके द्वारा अपेक्षित ट्रैफ़िक और डेटा की उपलब्धता पर भी निर्भर करता है जब भी आपको उनकी आवश्यकता होती है, विशेष रूप से डेटा पुनर्प्राप्ति के दौरान जहां डेटा गलती से हटा दिया गया था या डिस्क भ्रष्टाचार - जो अपरिहार्य हैं। ऐसी स्थितियां भी हैं कि डेटा हानि प्रतिलिपि प्रस्तुत करने योग्य है या मैन्युअल रूप से डुप्लिकेट किया जा सकता है जैसे उदाहरण के लिए, रिपोर्ट जनरेशन, थंबनेल, या कैश्ड डेटा। हालांकि सवाल इस बात पर निर्भर करता है कि जब भी कोई आपदा आती है तो आपको उनकी तुरंत कितनी आवश्यकता होती है; जब संभव हो, आप तार्किक और भौतिक बैकअप उपलब्धता का लाभ उठाने के लिए MySQL के लिए दैनिक आधार पर mysqldump और xtrabackup बैकअप दोनों लेना चाहेंगे। और भी अधिक आधारों को कवर करने के लिए, आप प्रति दिन कई वृद्धिशील एक्स्ट्राबैकअप रन शेड्यूल करना चाह सकते हैं। यह पूर्ण बैकअप लेने की तुलना में कुछ डिस्क स्थान, डिस्क I/O, या यहां तक ​​कि CPU I/O को भी बचा सकता है।

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

उन्नत सेटिंग अधिक ग्रैन्युलैरिटी के लिए क्रोन जैसी कॉन्फ़िगरेशन का लाभ उठाएगी। नीचे दी गई छवि देखें:

जब भी कोई विफलता होती है, ClusterControl इन मुद्दों को कुशलता से संभालता है और बैकअप विफलता के और निदान के लिए लॉग तैयार करता है।

आपके द्वारा चुने गए बैकअप प्रकार के आधार पर, कॉन्फ़िगर करने के लिए अलग सेटिंग्स हैं। Xtrabackup और Galera Cluster के लिए, आपके पास यह चुनने के विकल्प हो सकते हैं कि चलने पर आपका भौतिक बैकअप कौन-सी सेटिंग लागू करेगा। नीचे देखें:

• संपीड़न का उपयोग करें
• संपीड़न स्तर
• बैकअप के दौरान डिसिंक नोड
• बैकअप लॉक
• प्रति टेबल डीडीएल लॉक करें
• एक्सट्राबैकअप समानांतर कॉपी थ्रेड
• नेटवर्क स्ट्रीमिंग थ्रॉटल रेट (एमबी/एस)
• समानांतर gzip के लिए PIGZ का उपयोग करें
• एन्क्रिप्शन सक्षम करें
• अवधारण

आप नीचे दी गई छवि में देख सकते हैं कि आप तदनुसार विकल्पों को कैसे फ़्लैग कर सकते हैं और टूलटिप आइकन हैं जो उन विकल्पों की अधिक जानकारी प्रदान करते हैं जिन्हें आप अपनी बैकअप नीति के लिए लाभ उठाना चाहते हैं।

आपकी बैकअप नीति के आधार पर, ClusterControl को अप-टू-डेट उपलब्ध आपके बैकअप लेने के लिए सर्वोत्तम प्रथाओं के अनुसार तैयार किया जा सकता है। अपनी बैकअप नीति को परिभाषित करने पर, यह अनुमान लगाया जाता है कि आपके पास हार्डवेयर से सॉफ़्टवेयर से लेकर क्लाउड, टिकाऊपन, उच्च उपलब्धता, या मापनीयता तक अपना आवश्यक सेटअप उपलब्ध होना चाहिए।

गैलेरा क्लस्टर पर बैकअप लेते समय, बैकअप के चलने के दौरान गैलेरा नोड wsrep_desync=ON सेट करना एक अच्छा अभ्यास है। यह फ्लो कंट्रोल में भाग लेने से नोड को बाहर निकाल देगा और पूरे क्लस्टर को प्रतिकृति अंतराल से बचाएगा, खासकर यदि आपके डेटा का बैकअप लिया जाना बड़ा है। ClusterControl में, कृपया ध्यान रखें कि यह आपके लक्ष्य बैकअप नोड को लोड बैलेंसिंग सेट से भी हटा सकता है। यह विशेष रूप से सच है यदि आप HAProxy, ProxySQL, याMaxScale प्रॉक्सी का उपयोग करते हैं। यदि आपके पास नोड डिसिंक होने की स्थिति में अलर्ट मैनेजर सेट है, तो आप उस अवधि के दौरान बंद कर सकते हैं जब बैकअप चालू हो गया हो।

गैलेरा क्लस्टर या प्रतिकृति मास्टर पर बैकअप के प्रभाव को कम करने का एक अन्य लोकप्रिय तरीका एक प्रतिकृति दास को तैनात करना और फिर इसे बैकअप के स्रोत के रूप में उपयोग करना है - इस तरह गैलेरा क्लस्टर किसी भी बिंदु पर बैकअप के रूप में प्रभावित नहीं होगा। गुलाम को क्लस्टर से अलग कर दिया जाता है।

आप क्लस्टरकंट्रोल का उपयोग करके कुछ ही क्लिक में ऐसे दास को तैनात कर सकते हैं। नीचे दी गई छवि देखें:

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

और आप मौजूदा प्रतिकृति स्लेव को भी सेटअप कर सकते हैं,

PostgreSQL के लिए, आपके पास तार्किक या भौतिक बैकअप का बैकअप लेने के विकल्प हैं। ClusterControl में, आप pg_dump या pg_basebackup का चयन करके अपने PostgreSQL बैकअप का लाभ उठा सकते हैं। pg_basebackup 9.3 से पुराने संस्करणों के लिए काम नहीं करेगा।

MongoDB के लिए, ClusterControl mongodump या mongodb संगत प्रदान करता है। आपको यह ध्यान रखना पड़ सकता है कि मोंगोडब संगत आरएचईएल 7 का समर्थन नहीं करता है, लेकिन आप इसे मैन्युअल रूप से स्थापित करने में सक्षम हो सकते हैं।

डिफ़ॉल्ट रूप से, ClusterControl उन सभी बैकअप के लिए एक रिपोर्ट सूचीबद्ध करेगा, जो सफल या असफल हो चुके हैं। नीचे देखें:

आप ClusterControl का उपयोग करके बनाई गई या शेड्यूल की गई बैकअप रिपोर्ट की सूची देख सकते हैं। सूची के भीतर, आप आगे की जांच और निदान के लिए लॉग देख सकते हैं। उदाहरण के लिए, यदि बैकअप आपकी वांछित बैकअप नीति के अनुसार सही ढंग से समाप्त हुआ, क्या संपीड़न और एन्क्रिप्शन सही तरीके से सेट है, या यदि वांछित बैकअप डेटा आकार सही है। यह एक त्वरित विवेक जांच करने का एक अच्छा तरीका है - यदि आपका डेटासेट लगभग 1GB आकार का है, तो पूर्ण बैकअप 100KB जितना छोटा नहीं हो सकता है - कुछ बिंदु पर कुछ गलत हो गया होगा।

आपदा रिकवरी

क्लस्टर के भीतर बैकअप संग्रहीत करना (या तो सीधे डेटाबेस नोड पर या ClusterControl होस्ट पर) तब काम आता है जब आप अपने डेटा को जल्दी से पुनर्स्थापित करना चाहते हैं:सभी बैकअप फ़ाइलें जगह पर होती हैं और उन्हें डीकंप्रेस किया जा सकता है और तुरंत पुनर्स्थापित किया जा सकता है। जब डिजास्टर रिकवरी (DR) की बात आती है, तो यह सबसे अच्छा विकल्प नहीं हो सकता है। अलग-अलग मुद्दे हो सकते हैं - सर्वर क्रैश हो सकते हैं, नेटवर्क मज़बूती से काम नहीं कर सकता है, यहां तक ​​कि किसी तरह के आउटेज के कारण पूरे डेटा सेंटर तक पहुंच नहीं हो सकती है। ऐसा हो सकता है कि आप एक एकल डेटा केंद्र के साथ एक छोटे सेवा प्रदाता के साथ काम करते हैं, या अमेज़ॅन वेब सेवाओं जैसे वैश्विक विक्रेता के साथ काम करते हैं। इसलिए अपने सभी अंडों को एक टोकरी में रखना सुरक्षित नहीं है - आपको यह सुनिश्चित करना चाहिए कि आपके पास अपने बैकअप की एक प्रति किसी बाहरी स्थान पर संग्रहीत है। ClusterControl Amazon S3, Google Storage और Azure Cloud Storage को सपोर्ट करता है।

जो लोग अपनी स्वयं की DR नीतियों को लागू करना चाहते हैं, उनके लिए ClusterControl बैकअप एक अच्छी तरह से संरचित निर्देशिका में संग्रहीत किए जाते हैं। आपके पास अपने बैकअप को क्लाउड पर अपलोड करने का विकल्प भी है। नीचे दी गई छवि देखें:

आप Amazon Web Services, Google Cloud, और Microsoft Azure को चुनकर अपलोड कर सकते हैं। नीचे दी गई छवि देखें:

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

अपने DR के लिए एक तार्किक या भौतिक बैकअप बनाने के अलावा, अपने डेटा का एक पूर्ण स्नैपशॉट बनाना (जैसे LVM स्नैपशॉट, Amazon EBS स्नैपशॉट का उपयोग करना, या वॉल्यूम स्नैपशॉट का उपयोग करना यदि वेरिटास फ़ाइल सिस्टम का उपयोग कर रहा है) आपके बैकअप पुनर्प्राप्ति को बढ़ा सकता है। आप अपने पॉइंट इन टाइम रिकवरी (PITR) या अपने PITR के लिए अपने MySQL बाइनरी लॉग के लिए WAL (पोस्टग्रेज के लिए) का भी उपयोग कर सकते हैं। इस प्रकार, आपको यह विचार करना होगा कि आपको अपने PITR के लिए अपना स्वयं का संग्रह बनाने की आवश्यकता हो सकती है। इसलिए स्क्रिप्ट का अपना सेट बनाना और तैनात करना और अपनी सटीक आवश्यकताओं के अनुसार DR को संभालना पूरी तरह से ठीक है।

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

अंत में और सबसे महत्वपूर्ण बात, एक बैकअप जिसका परीक्षण नहीं किया गया है, एक असत्यापित बैकअप, उर्फ ​​श्रोएडिंगर बैकअप बना रहता है। यह सुनिश्चित करने के लिए कि आपके पास एक कार्यशील बैकअप है, आपको पुनर्प्राप्ति परीक्षण करने की आवश्यकता है। ClusterControl आपके बैकअप को स्वचालित रूप से सत्यापित और परीक्षण करने का एक तरीका प्रदान करता है।

हमें उम्मीद है कि इससे आपको अपने ओपन सोर्स डेटाबेस के लिए एक सुरक्षित और विश्वसनीय बैकअप प्रक्रिया बनाने के लिए पर्याप्त जानकारी मिल जाएगी।