क्या यह गिट के साथ MySQL बैकअप को संभालने के लिए व्यवहार्य है?

Question

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

हालांकि, मुझे पता है कि चालाक समाधानों में कभी-कभी मौलिक त्रुटियां होती हैं। गिट में mysqldump diffs को संग्रहीत करने के लिए मैं किस तरह के मुद्दों को मार सकता हूं? यह इसके लायक है? सर्वर पर एकाधिक डेटाबेस बैकअप रखने के लिए अधिकांश लोग क्या करते हैं और अनावश्यक प्रतियां कहीं और रखते हैं?

Answer 1

यह दृष्टिकोण मेरे लिए ठीक लगता है। मैं अपने स्वयं के महत्वपूर्ण डेटा का बैक अप लेने के लिए गिट का उपयोग करता हूं।

ध्यान दें कि आप diffs संग्रहित नहीं कर रहे हैं - गिट प्रभावी ढंग से प्रत्येक प्रतिबद्धता के साथ निर्देशिका स्थिति के स्नैपशॉट स्टोर करता है। आप दो प्रतिबद्धताओं का अंतर उत्पन्न कर सकते हैं, लेकिन वास्तविक भंडारण तंत्र के पास भिन्नता से कोई लेना देना नहीं है।

Answer 2

आम तौर पर आप हमेशा के लिए हर बैकअप (या स्नैपशॉट) नहीं रखते हैं। एक गिट भंडार आपके द्वारा बनाए गए हर चेकइन को रखें। यदि आप कभी भी पुराने संशोधनों का अनुमान लगाने का फैसला करते हैं (सप्ताह में एक बार में महीने के पुराने संशोधन, महीने में एक वर्ष में एक बार, आदि) आपको git filter-branch के साथ ऐसा करना होगा जो पूरे इतिहास को फिर से लिख देगा। अवांछित संशोधन को हटाने के लिए git gc।

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

Answer 3

सिद्धांत में यह काम करेगा, लेकिन डेटाबेस डंप बड़े होने पर आपको समस्याएं शुरू हो जाएंगी।

गिट में कोई हार्ड फ़ाइल आकार सीमा नहीं है, लेकिन यह आपके नवीनतम डंप की सामग्री को पहले से भंडार में संग्रहीत किया जाएगा, जिसके लिए उन दोनों फ़ाइलों के आकार के रूप में कम से कम स्मृति की आवश्यकता होगी एक साथ जोड़ा गया - तो मुझे लगता है कि यह 100 एमबी (या यहां तक ​​कि 10 एमबी) से अधिक फ़ाइलों के साथ बहुत धीमी गति से शुरू हो जाएगा।

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

Answer 4

यदि आप MySQL (और संभवतः अन्य) का उपयोग कर रहे हैं और बाइनरी लॉगिंग सक्षम हैं, तो आप अपने बिन लॉग की निर्देशिका के लिए एक गिट रेपो स्थापित करने और बिनलॉग को नियमित रूप से अपडेट करने की रणनीति विकसित करने पर विचार कर सकते हैं।

MySQL में, बिनलॉग उन प्रश्नों को संग्रहीत करता है जो डेटाबेस पर किसी भी तालिका में डेटा बदलते हैं। यदि आप डेटाबेस के नियमित डंप के साथ अपना काम सिंक करते हैं, तो आपके पास डेटा को पुनर्स्थापित करने के लिए एक संस्करण तरीका होना चाहिए।

ईमानदारी से, मुझे लगता है कि केवल MySQL के मूल उपकरण का उपयोग करना बेहतर समाधान होगा, लेकिन जो मैंने यहां बताया है, वह आपको अपने MySQL डेटा को संस्करणित कर देता है जो मुझे लगता है कि आप पहले स्थान पर थे।