MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

ClusterControl के साथ डेटाबेस बैकअप कैसे शेड्यूल करें

डेटाबेस बैकअप डेटाबेस प्रबंधन का एक महत्वपूर्ण हिस्सा है, और इसकी सावधानीपूर्वक योजना बनाई जानी चाहिए। बैकअप शेड्यूल करना पर्याप्त नहीं है, बैकअप डेटा को भी निरंतरता और अखंडता के लिए सत्यापित करने की आवश्यकता है। एन्क्रिप्शन, और ऑफ-साइट संग्रह करने जैसे अन्य विचार हैं। एक अच्छे बैकअप प्रबंधक में ऐसी विशेषताएं होंगी जो इन सभी विभिन्न विचारों को ध्यान में रखती हैं।

इस ब्लॉग पोस्ट में, हम यह देखने जा रहे हैं कि आप अपने डेटाबेस बैकअप को ClusterControl के साथ कैसे शेड्यूल कर सकते हैं।

ClusterControl का उपयोग कर डेटाबेस बैकअप

ClusterControl क्लस्टर प्रकार के आधार पर कई बैकअप विधियों का समर्थन करता है, जैसा कि निम्न तालिका में संक्षेपित किया गया है:

क्लस्टर प्रकार समर्थित बैकअप विधि
MySQL (प्रतिकृति, गैलेरा, NDB क्लस्टर, समूह प्रतिकृति)
  • mysqldump
  • पेरकोना एक्स्ट्राबैकअप (पूर्ण और वृद्धिशील)
  • मारियाडीबी बैकअप (केवल मारियाडीबी)
  • NDB बैकअप (केवल MySQL क्लस्टर)
MongoDB (प्रतिकृति सेट, साझा क्लस्टर)
  • मोंगोडंप
  • मोंगोडब-संगत-बैकअप (बीटा, पेरकोना सर्वर केवल मोंगोडीबी के लिए)
PostgreSQL (स्ट्रीमिंग प्रतिकृति)
  • pg_dumpall
  • pg_basebackup

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

  • डिस्क IOPS थ्रॉटलिंग
  • नेटवर्क थ्रॉटलिंग
  • बैकअप लॉक
  • एन्क्रिप्शन
  • संपीड़न
  • अवधारण अवधि
  • सत्यापन

विशेष डेटाबेस विक्रेता से सर्वोत्तम अभ्यास का पालन करते हुए, ClusterControl स्वचालित रूप से कई बैकअप विकल्प सेट करेगा। उदाहरण के लिए, यदि लक्ष्य डेटाबेस नोड में बाइनरी लॉग सक्षम है, तो यह एक अतिरिक्त ध्वज जोड़ देगा, --मास्टर-डेटा डंप किए गए सर्वर के बाइनरी लॉग निर्देशांक (फ़ाइल का नाम और स्थिति) शामिल करने के लिए। यदि यह गैलेरा नोड है और बैकअप विधि xtrabackup है, तो ClusterControl एक अतिरिक्त ध्वज जोड़ देगा, --galera-info जिसमें बैकअप के समय स्थानीय नोड स्थिति होती है।

बैकअप की योजना बनाना

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

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

आम तौर पर, उन सवालों के जवाब देकर, हम एक उपयुक्त बैकअप रणनीति के साथ आ सकते हैं। आपकी बैकअप और बहाली नीति के आधार पर प्रश्नों की सूची लंबी हो सकती है।

हमने इस अध्याय को अपने श्वेतपत्र, MySQL और MariaDB के लिए डेटाबेस बैकअप के लिए DevOps गाइड में विस्तार से शामिल किया है।


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

ClusterControl के साथ, शेड्यूलिंग बहुत सरल है। सीधे बैकअप पर जाएं -> बैकअप बनाएं -> बैकअप शेड्यूल करें और आपको निम्नलिखित संवाद के साथ प्रस्तुत किया जाएगा:

क्लस्टर प्रकार के आधार पर, विकल्प भिन्न हो सकते हैं, जैसा कि PostgreSQL और MongoDB के लिए निम्नलिखित स्क्रीनशॉट में दिखाया गया है:

PostgreSQL MongoDB

अधिकांश विकल्प स्व-व्याख्यात्मक हैं, और उपयोगकर्ता मार्गदर्शिका में विवरण में शामिल हैं। एक बार शेड्यूल बन जाने के बाद, आप कॉन्फ़िगरेशन बैकअप को संपादित कर सकते हैं, बैकअप को सक्षम/अक्षम कर सकते हैं या "शेड्यूल बैकअप" टैब के अंतर्गत शेड्यूल को हटा सकते हैं:

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

आप एक बार समय आने पर गतिविधि -> नौकरियां देखकर बैकअप की प्रगति की निगरानी कर सकते हैं। यदि बैकअप कार्य विफल हो जाता है, तो आपको तुरंत त्रुटि दिखाई देगी:

उपरोक्त लॉग प्रत्येक बैकअप प्रविष्टि पर बैकअप टैब के अंतर्गत भी पहुंच योग्य है:

बैकअप के बाद की जांच और सत्यापन

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

के तहत गंभीरता के आधार पर विन्यास योग्य है।

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

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

"स्टैंडअलोन होस्ट पर पुनर्स्थापित और सत्यापित करें" के लिए एक अलग होस्ट की आवश्यकता होती है, जो पहले से ही डेटाबेस सेटअप का हिस्सा नहीं है। क्लस्टरकंट्रोल पहले लक्ष्य होस्ट पर एक MySQL इंस्टेंस को तैनात करेगा, सेवा शुरू करेगा, बैकअप रिपोजिटरी से बैकअप कॉपी करेगा और बहाली शुरू करेगा। एक बार हो जाने के बाद, आपके पास एक विकल्प हो सकता है कि या तो सर्वर को बहाल करने के बाद बंद कर दिया जाए या इसे चलने दिया जाए ताकि आप सर्वर पर आगे की जांच कर सकें।

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

यदि बैकअप संग्रहण किसी स्थान की सीमा के करीब पहुंच रहा है, या आप अपने बैकअप को ऑफ़साइड संग्रहित करना चाहते हैं, तो आप ट्रैश बिन आइकन पर क्लिक करके फ़ाइल को मैन्युअल रूप से हटाना चुन सकते हैं या इसे क्लाउड पर अपलोड कर सकते हैं, जैसा कि नीचे हाइलाइट किया गया है:

लेखन के समय, AWS S3 और GCP क्लाउड स्टोरेज समर्थित हैं। क्लाउड क्रेडेंशियल्स को साइड मेन्यू -> इंटीग्रेशन -> क्लाउड प्रोवाइडर्स के तहत पूर्व-कॉन्फ़िगर किया जाना चाहिए।

यही है, दोस्तों। हैप्पी क्लस्टरिंग!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MaxScale का उपयोग करके एक इंटरमीडिएट MySQL या MariaDB मास्टर को बिनलॉग सर्वर से कैसे बदलें

  2. मारियाडीबी में SQRT () कैसे काम करता है

  3. मारियाडीबी माइनस ऑपरेटर ने समझाया

  4. मारियाडीबी सर्वर के नवीनतम संस्करण के साथ नवीनतम जीरा में अपग्रेड करना

  5. मारियाडीबी CHARACTER_LENGTH () समझाया गया