MySQL में डेटा का बैकअप लेना

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

1. डेटाबेस फ़ाइलों की प्रतिलिपि बनाना

आप MySQL डेटाबेस को कॉपी कर सकते हैं यदि आप अस्थायी रूप से MySQL सर्वर को बंद कर देते हैं और बस / var / lib / mysql / db / फ़ोल्डर से फाइल कॉपी करते हैं। यदि सर्वर बंद नहीं है, तो स्पष्ट कारणों से, डेटा हानि और भ्रष्टाचार की संभावना है। बड़े लोड किए गए आधारों के लिए, यह संभावना 100% के करीब है। इसके अलावा, पहली बार जब आप डेटाबेस की एक गंदी प्रतिलिपि के साथ शुरू करते हैं, तो MySQL सर्वर पूरे डेटाबेस की जांच की प्रक्रिया शुरू कर देगा, जिसमें घंटों लग सकते हैं।

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

कुछ फाइल सिस्टम, जैसे ZFS, देशी रूप से स्नैपशॉट हटाने का समर्थन करते हैं। यदि आप ZFS का उपयोग नहीं करते हैं, लेकिन LVM वॉल्यूम प्रबंधक आपके सर्वर पर स्थापित है, तो आप स्नैपशॉट के माध्यम से MySQL डेटाबेस की प्रतिलिपि भी बना सकते हैं। अंत में, * nix के तहत, आप R1Soft हॉट कॉपी स्नैपशॉट ड्राइवर का उपयोग कर सकते हैं, लेकिन यह विधि ओपनविज़ कंटेनर ( MySQL बैकअप प्रक्रिया यहाँ वर्णित है ) में काम नहीं करेगी।

MyISAM डेटाबेस के लिए एक आधिकारिक मुफ्त mysqlhotcopy उपयोगिता है जो सर्वर को बंद किए बिना "सही ढंग से" MyISAM डेटाबेस फ़ाइलों की प्रतिलिपि बनाता है। InnoDB के लिए एक समान उपयोगिता है , लेकिन इसका भुगतान किया जाता है, हालांकि इसमें अधिक विशेषताएं हैं।

फ़ाइलों को कॉपी करना पूरे डेटाबेस को एक सर्वर से दूसरे सर्वर में स्थानांतरित करने का सबसे तेज़ तरीका है।

2. पाठ फ़ाइलों के माध्यम से नकल

उत्पादन डेटाबेस से डेटा को बैकअप में पढ़ने के लिए, फ़ाइलों को खींचने के लिए आवश्यक नहीं है। आप क्वेरी द्वारा डेटा का चयन कर सकते हैं और इसे टेक्स्ट फ़ाइल में सहेज सकते हैं। ऐसा करने के लिए, SQL कमांड SELECT INTO OUTFILE और उसके युग्मित LOAD DATA INFILE का उपयोग करें । उतराई लाइन द्वारा किया जाता है (आप सामान्य रूप से चयन के रूप में, बचाने के लिए केवल आवश्यक लाइनों का चयन कर सकते हैं)। टेबल संरचना कहीं भी निर्दिष्ट नहीं है - प्रोग्रामर को इस बात का ध्यान रखना चाहिए। डेटा अखंडता सुनिश्चित करने के लिए आवश्यक होने पर, लेन-देन में SELECT INTO OUTFILE के बयानों को शामिल करने का भी ध्यान रखना चाहिए। व्यवहार में, SELECT INTO OUTFILE का उपयोग आंशिक रूप से बहुत बड़ी तालिकाओं के बैकअप के लिए किया जाता है जिसे किसी अन्य तरीके से कॉपी नहीं किया जा सकता है।

ज्यादातर मामलों में, इगोर रोमानेंको द्वारा बनाई गई mysqldump उपयोगिता कहीं अधिक सुविधाजनक है। Mysqldump उपयोगिता एक फ़ाइल को उत्पन्न करता है जिसमें डेटाबेस पर किसी अन्य सर्वर को पूरी तरह से पुनर्स्थापित करने के लिए आवश्यक सभी SQL कमांड होते हैं। व्यक्तिगत विकल्पों के साथ, आप लगभग किसी भी DBMS (न केवल MySQL) के साथ इस फ़ाइल की संगतता प्राप्त कर सकते हैं, इसके अलावा, CSV और XML प्रारूपों में डेटा अपलोड करने की संभावना है। ऐसे प्रारूपों से डेटा को पुनर्प्राप्त करने के लिए, mysqlimport उपयोगिता है।

Mysqldump कंसोल उपयोगिता। इसके ऐड-ऑन और एनालॉग्स हैं जो आपको वेब इंटरफ़ेस के माध्यम से बैकअप का प्रबंधन करने की अनुमति देते हैं, उदाहरण के लिए, यूक्रेनी उपकरण Sypex Dumper (उनके प्रतिनिधि zapimir हब पर है)।

पाठ फ़ाइलों में सार्वभौमिक बैकअप उपयोगिताओं के नुकसान अपेक्षाकृत कम गति और वृद्धिशील बैकअप बनाने की क्षमता की कमी है।

3. वृद्धिशील बैकअप

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

ये आवश्यकताएं बड़े डेटाबेस के लिए एक समस्या हो सकती हैं। 100-mb नेटवर्क पर 100-गीगाबाइट बेस के बैकअप को पंप करने में तीन घंटे लगेंगे, जिससे चैनल पूरी तरह से बंद हो जाएगा।
वृद्धिशील बैकअप आंशिक रूप से इस समस्या को हल कर सकता है, जब एक पूर्ण बैकअप किया जाता है, कहते हैं, केवल रविवार को, और अन्य दिनों में केवल पिछले 24 घंटों में डेटा जोड़ा या बदला गया है। कठिनाई यह है कि इन "समान डेटा" को कैसे पहचाना जाए जो दिन के दौरान बदल गए।

यहाँ, पेरकोना XtraBackup सिस्टम, जिसमें संशोधित InnoDB इंजन शामिल है, MySQL बाइनरी लॉग का विश्लेषण करता है और उनमें से आवश्यक जानकारी को खींचता है, व्यावहारिक रूप से प्रतियोगिता से बाहर। ऊपर उल्लिखित सशुल्क InnoDB हॉट बैकअप में लगभग समान क्षमताएं हैं।

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

4. प्रतिकृति

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

प्रतिकृति बहुत शांत है, बस इसे अपने इच्छित उद्देश्य के लिए उपयोग करें। एक प्रतिकृति डेटाबेस की एक पूरी प्रतिलिपि है, लेकिन यह बैकअप नहीं है ! जाहिर है, यदि आप DROP टेबल या अद्यतन उपयोगकर्ताओं को निष्पादित करते हैं तो पासवर्ड सेट करें = "Haha!" विज़ार्ड पर, परिवर्तनों को तुरंत दास को कॉपी किया जाएगा और उन्हें वापस रोल करना असंभव हो जाएगा।

प्रतिकृति को आधार फ़ाइल स्तर पर बैकअप के साथ जोड़ा जा सकता है, दास को रोककर, विज़ार्ड को नहीं।

एक निष्कर्ष के बजाय

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