ClusterControl 1.5 - स्वचालित बैकअप सत्यापन, बैकअप और क्लाउड एकीकरण से दास बनाएँ

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

हमारी नवीनतम रिलीज़, ClusterControl 1.5 में, हमने MySQL और MariaDB-आधारित सिस्टम के बैकअप के लिए कई एन्हांसमेंट पेश किए हैं।

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

आइए, ClusterControl 1.5 के लिए सभी रोमांचक नई बैकअप सुविधाओं के बारे में जानें...

बैकअप/रिस्टोर विजार्ड रिडिजाइन

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

बैकअप सूची में एक छोटा बदलाव भी हो रहा है जहां बैकअप विवरण प्रदर्शित होते हैं जब आप विशेष बैकअप पर क्लिक करते हैं:

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

PITR संगत बैकअप

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

एक mysqldump PITR- संगत बैकअप में एक सिंगल डंप फ़ाइल होती है, जिसमें GTID जानकारी, बिनलॉग फ़ाइल और स्थिति होती है। इस प्रकार, केवल डेटाबेस नोड जो बाइनरी लॉग उत्पन्न करता है, उसके पास "PITR संगत" विकल्प उपलब्ध होगा, जैसा कि नीचे स्क्रीनशॉट में हाइलाइट किया गया है:

जब PITR संगत विकल्प को टॉगल किया जाता है, तो डेटाबेस और टेबल फ़ील्ड धूसर हो जाते हैं क्योंकि ClusterControl हमेशा लक्ष्य MySQL सर्वर के सभी डेटाबेस, ईवेंट, ट्रिगर और रूटीन के विरुद्ध बैकअप निष्पादित करेगा।

निम्नलिखित पंक्तियाँ पूर्ण डंप फ़ाइल की पहली ~50 पंक्तियों में दिखाई देंगी:

$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';

--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...

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

एक बार मंचन पूरा हो जाने पर, दास चुने हुए गुरु से जुड़ जाएगा और पकड़ना शुरू कर देगा। पहले, ClusterControl ने Percona Xtrabackup का उपयोग करके सीधे चुने हुए मास्टर से स्ट्रीमिंग बैकअप का प्रदर्शन किया। यह बड़े डेटासेट को स्केल करते समय मास्टर के प्रदर्शन को प्रभावित कर सकता है, भले ही मास्टर पर ऑपरेशन नॉन ब्लॉकिंग हो। नए विकल्प के साथ, यदि बैकअप ClusterControl पर संग्रहीत है, तो केवल ये होस्ट (ClusterControl + स्लेव) स्लेव पर डेटा को स्टेज करते समय व्यस्त रहेंगे।

क्लाउड का बैकअप लें

बैकअप अब स्वचालित रूप से क्लाउड में अपलोड किए जा सकते हैं। इसके लिए एक ClusterControl मॉड्यूल स्थापित करने की आवश्यकता है, जिसे क्लस्टरकंट्रोल-क्लाउड . कहा जाता है (क्लाउड इंटीग्रेशन मॉड्यूल) और क्लस्टरकंट्रोल-क्लड (क्लाउड डाउनलोड/अपलोड सीएलआई) जो v1.5 और बाद के संस्करण में उपलब्ध हैं। इन पैकेजों के साथ अपग्रेड निर्देश शामिल किए गए हैं और वे बिना किसी अतिरिक्त कॉन्फ़िगरेशन के आते हैं। फिलहाल, समर्थित क्लाउड प्लेटफॉर्म Amazon Web Services और Google Cloud Platform हैं। क्लाउड क्रेडेंशियल्स क्लस्टरकंट्रोल -> सेटिंग्स -> इंटीग्रेशन -> क्लाउड प्रोवाइडर्स के तहत कॉन्फ़िगर किए गए हैं।

बैकअप बनाते या शेड्यूल करते समय, "क्लाउड पर बैकअप अपलोड करें" टॉगल होने पर आपको निम्नलिखित अतिरिक्त विकल्प दिखाई देने चाहिए:

यह सुविधा एक बार अपलोड करने या पूरा होने के बाद बैकअप को शेड्यूल करने की अनुमति देती है (अमेज़ॅन एस 3 या Google क्लाउड स्टोरेज)। फिर आप आवश्यकतानुसार बैकअप डाउनलोड और पुनर्स्थापित कर सकते हैं।

mysqldump के लिए कस्टम संपीड़न

यह सुविधा वास्तव में इसके रिलीज होने के बाद सबसे पहले ClusterControl v1.4.2 के साथ पेश की गई थी। हमने gzip के आधार पर एक बैकअप संपीड़न स्तर जोड़ा है। पहले, यदि बैकअप गंतव्य नियंत्रक नोड पर था, तो ClusterControl ने डिफ़ॉल्ट बैकअप संपीड़न (स्तर 6) का उपयोग किया। यदि कंप्रेसिंग ऑपरेशन के दौरान डेटाबेस पर न्यूनतम प्रभाव सुनिश्चित करने के लिए बैकअप गंतव्य डेटाबेस होस्ट पर ही था, तो निम्नतम संपीड़न (स्तर 1 - सबसे तेज़, कम संपीड़न) का उपयोग किया गया था।

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

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

बोनस सुविधा:स्वचालित बैकअप सत्यापन

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

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

बैकअप बनाते या शेड्यूल करते समय, यदि "बैकअप सत्यापित करें" को टॉगल किया जाता है, तो आपके पास अतिरिक्त विकल्प होंगे:

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

बोनस फ़ीचर:PostgreSQL को न भूलें

MySQL और MariaDB ClusterControl 1.5 के लिए इस सभी महान कार्यक्षमता के अलावा अब PostgreSQL को एक अतिरिक्त बैकअप विधि (pg_basebackup) भी प्रदान करता है जिसका उपयोग ऑनलाइन बाइनरी बैकअप के लिए किया जा सकता है। pg_basebackup के साथ लिए गए बैकअप का उपयोग बाद में पॉइंट-इन-टाइम पुनर्प्राप्ति के लिए और लॉग शिपिंग या स्ट्रीमिंग प्रतिकृति स्टैंडबाय सर्वर के लिए शुरुआती बिंदु के रूप में किया जा सकता है।

अभी के लिए बस इतना ही। ClusterControl v1.5 को आजमाएं, नई सुविधाओं के साथ खेलें और हमें बताएं कि आप क्या सोचते हैं।