सफल MySQL/MariaDB बैकअप और पुनर्प्राप्ति रणनीतियाँ

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

बैकअप रणनीतियां

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

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

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

बैकअप टूल

MySQL और MariaDB बैकअप और पुनर्प्राप्ति योजनाओं को स्थापित करने और निष्पादित करने के कई तरीके प्रदान करते हैं। इन विधियों में MySQL के एंटरप्राइज़ mysqlbackup टूल . के साथ भौतिक बैकअप शामिल हैं , मारियाडीबी का मारियाबैकअप टूल , या पेरकोना का एक्स्ट्राबैकअप टूल . साथ ही, Mysql के mysqldump टूल . के साथ बनाए गए तार्किक बैकअप काम आ सकता है। एक अन्य विकल्प पहले बताए गए टूल के संयोजन में डेटाबेस बिन-लॉग्स (लेन-देन लॉग) के साथ पॉइंट-इन-टाइम रिकवरी है।

विफलता या आपदा के मामले में डेटाबेस पुनर्प्राप्ति क्षमता को अधिकतम करने के लिए आप अपनी बैकअप रणनीति में उपयुक्त तरीकों को आत्मसात कर सकते हैं।

नोट:मारियाडीबी संस्करण 10.4.6 में, mysqldump's symlink मारीडब-डंप . कहा जाता है . बाद के संस्करणों में, 10.5.2 सहित, नाम फिर से बदल गए - mysqldump बन गया सिम्लिंक ।

प्रक्रियाओं को स्पष्ट करने के लिए, मैं मारियाबैकअप टूल का उपयोग करूंगा भौतिक बैकअप बनाने के लिए। टूल की बुनियादी कार्यक्षमता उपरोक्त टूल की तरह ही है, हालांकि प्रत्येक टूल के लिए कुछ मामूली अंतर अद्वितीय हैं।

भौतिक डेटाबेस बैकअप

भौतिक बैकअप फ़ाइल-स्तरीय बैकअप हैं जो आपको तेज़ फ़ाइल प्रतिलिपि बनाने के तरीके प्रदान करते हैं। ऐसे बैकअप डिजास्टर-रिकवरी परिदृश्यों, क्लोनिंग डेटाबेस और/या स्लेव डेटाबेस बनाने में बेहतर होते हैं।

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

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

एक और क्षण जिस पर आपको ध्यान देना चाहिए, वह यह है कि जब आप भौतिक बैकअप से डेटा पुनर्प्राप्त करते हैं, तो आपको अंतिम पुनर्प्राप्ति चरण पूर्ण होने तक अपनी MySQL/MariaDB डेटाबेस आवृत्ति प्रक्रिया को रोकना होगा।

आप एक साधारण पूर्ण भौतिक बैकअप का निष्पादन निम्नानुसार कर सकते हैं:

 mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220 \
   --user=backupuser --password=backuppasswd

–target-dir विकल्प बैकअप टूल को बताता है कि बैकअप को कहाँ रखा जाए।

इस उदाहरण में, मैंने अपने बैकअप को DYYYYMMDD नामक निर्देशिका में व्यवस्थित किया है जहां प्रत्येक पूर्ण बैकअप संग्रहीत किया जाता है (D का अर्थ दैनिक है)। ऐसा करने में, हमारे पास एक विशिष्ट तिथि पर लिए गए बैकअप से डेटाबेस को पुनर्स्थापित करने के लिए एक आसान तरीका है।

अगला उदाहरण एक साधारण वृद्धिशील बैकअप निष्पादित करने को प्रदर्शित करता है:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc1/ \
   --incremental-basedir=/data/backups/mariadb/D20210220/ \
   --user=backupuser --password=backuppasswd

बाद का वृद्धिशील बैकअप इन पंक्तियों के साथ दिखेगा:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc2/ \
   --incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
   --user=backupuser --password=backuppasswd

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

अब, आइए जानें कि भौतिक डेटाबेस फ़ाइल का नाम क्या है जिसमें सभी निर्देशिका डेटा संग्रहीत हैं। डोमेन नियंत्रकों पर स्थित डेटाबेस एक सक्रिय निर्देशिका है। इस निर्देशिका का उपयोग उपयोगकर्ताओं, डेटा आदि को प्रबंधित करने के लिए किया जाता है। एक सक्रिय निर्देशिका का मूल NTDS.DIT डेटाबेस फ़ाइल है जिसमें लिंक, सुरक्षा डिस्क्रिप्टर और डेटा टेबल होते हैं। इस भौतिक डेटाबेस फ़ाइल में सभी निर्देशिका डेटा रखा जाता है।

भौतिक और तार्किक फ़ाइलों के बीच अंतर करना आवश्यक है। वास्तविक सिस्टम डेटा भौतिक फ़ाइलों में स्थित होता है, जबकि तार्किक फ़ाइलों में भौतिक फ़ाइलों में संग्रहीत रिकॉर्ड का विवरण होता है।

MySQL डेटाबेस को भौतिक फ़ाइलों से पुनर्स्थापित करने का कार्य कभी-कभी मुश्किल हो सकता है। mysqldump इस मामले में कमांड मददगार हो सकता है। हम इस विषय को आगे कवर करेंगे।

तार्किक डेटाबेस बैकअप

तार्किक बैकअप mysqldump . के साथ बनाए जाते हैं औजार। यह बैकअप विधि भौतिक बैकअप की तुलना में अधिक लचीली है। इसमें सभी डीएमएल और/या डीडीएल एसक्यूएल स्टेटमेंट होते हैं जो एक सुसंगत बैकअप बनाने के लिए आवश्यक होते हैं, सभी प्रतिबद्ध डेटा और बैकअप से पहले और दौरान किए गए परिवर्तनों को मिलाकर। यदि आप सभी डेटाबेस को बैकअप और पुनर्स्थापित करने के तरीके के बारे में अधिक जानना चाहते हैं, तो आप इस लेख को पढ़ सकते हैं।

तार्किक बैकअप एक फ़ाइल या एकाधिक फ़ाइलें (एक विशिष्ट स्क्रिप्ट के साथ बनाई गई) हो सकती है। इसके अलावा, आप अपने MySQL/MariaDB उदाहरण (प्रक्रिया) को बंद किए बिना संरचना और/या डेटा को पुनर्स्थापित कर सकते हैं। तदनुसार, तार्किक बैकअप डेटाबेस और/या तालिका स्तर पर किए जाते हैं, जबकि भौतिक बैकअप फ़ाइल सिस्टम स्तर (निर्देशिका और फ़ाइलें) पर होते हैं।

यह भी ध्यान दें कि तार्किक बैकअप विशेष रूप से इच्छित डेटाबेस और/या तालिकाओं की पूर्ण बैकअप छवियां हैं।

संपूर्ण MySQL/MariaDB उदाहरण का तार्किक बैकअप बनाना नीचे है:

mysqldump --all-databases --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql

ध्यान दें कि भौतिक बैकअप और तार्किक बैकअप बैकअप प्रबंधन उद्देश्यों के लिए फाइल सिस्टम में विशेष रूप से प्रतिष्ठित हैं।

पिछले उदाहरण के विपरीत, एकल डेटाबेस (स्कीमा) का तार्किक बैकअप निम्न तरीके से बनाया जाता है:

mysqldump empdb --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql

अंत में, डेटाबेस में एकल तालिका का तार्किक बैकअप बनाने के लिए, डेटाबेस के बाद तालिका का नाम जोड़ें:

mysqldump empdb departments --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql

जब आपको पुनर्प्राप्ति परिदृश्य में DROP DATABASE या DROP TABLE कथनों को संपादित करने और जोड़ने की आवश्यकता होती है, तो बड़ी बैकअप फ़ाइलों के साथ काम करने से टेक्स्ट संपादकों पर उनके दम घुटने तक सीमित प्रभाव पड़ सकते हैं।

ऐसे मामलों में, अन्य विकल्प जोड़ने पर विचार करें, जैसे –ऐड-ड्रॉप-डेटाबेस और/या –ऐड-ड्रॉप-टेबल इन DROP स्टेटमेंट को बैकअप में शामिल करने के लिए। अन्य परिदृश्यों में, आप इन कथनों को बाहर करना और उन्हें –स्किप-ऐड-ड्रॉप-टेबल से प्रतिस्थापित करना चाह सकते हैं। कमांड का विकल्प।

हालांकि, आप –no-create-info का उपयोग करके केवल-डेटा या केवल-DDL-बैकअप भी बना सकते हैं या –कोई डेटा नहीं विकल्प। कुछ पुनर्प्राप्ति परिदृश्यों में अलग डेटा और संरचना बैकअप एक अच्छा विकल्प हो सकता है, खासकर जब आपको खाली क्लोन डेटाबेस और/या इसकी तालिकाओं को बनाने के लिए केवल DDL संरचना की आवश्यकता होती है।

डिस्क स्नैपशॉट का उपयोग करके डेटाबेस का बैकअप लेना

जैसे-जैसे डेटा बढ़ता है, इसे कई डिस्क और/या फाइल सिस्टम पर व्यवस्थित करना आवश्यक हो सकता है। प्रदर्शन कारणों के अलावा, जैसा कि I/O कई डिस्क/फाइल सिस्टम में वितरित किया जाता है, आपको यह सुनिश्चित करना होगा कि कुशल बैकअप और पुनर्प्राप्ति रणनीतियों में डिस्क और फाइल सिस्टम स्नैपशॉट क्षमताएं शामिल हैं।

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

innodb_home_dir = /<path where your InnoDB tables will reside>

या, आप DATA_DIRECTORY . का उपयोग कर सकते हैं और INDEX_DIRECTORY बनाएं . में विकल्प तालिका विवरण उन्हें अलग-अलग फाइल सिस्टम स्थानों में अलग-अलग वितरित करने के लिए।

InnoDB के लिए, file_per_table =ON . का उपयोग करना सुनिश्चित करें (नवीनतम संस्करणों में डिफ़ॉल्ट चालू)। InnoDB तालिकाओं को बनाते समय सावधानी से पथ चुनें। तालिका को गिराए और फिर से बनाए बिना पथ को बदलना असंभव है।

अंतर्निहित स्नैपशॉट क्षमताओं के साथ उचित फाइल सिस्टम का होना मददगार है, उदा। लिनक्स पर एक्सएफएस और जेडएफएस। ध्यान दें कि स्नैपशॉट बैकअप बनाना भौतिक बैकअप बनाने के समान है, लेकिन इसकी विशिष्टताएँ हैं। इसके लिए लेखन प्रक्रिया को रोकने की आवश्यकता है (READ LOCK के साथ फ्लश करें या इसी तरह — देखें बैकअप चरण स्नैपशॉट लेने से पहले और LOCKS . जारी करने से पहले MariaDB ऑनलाइन दस्तावेज़ में आदेश दें स्नैपशॉट के पूरा होने के तुरंत बाद। डेटा एकरूपता सुनिश्चित करना आवश्यक है।

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

पुनर्प्राप्ति रणनीतियां

भौतिक बैकअप से पुनर्प्राप्ति

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

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

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

एक अन्य महत्वपूर्ण बिंदु है, जब आप बैकअप तैयार करते हैं, शामिल पूर्ण बैकअप को किसी अन्य स्थान पर कॉपी करें समय-समय पर निरंतरता सुनिश्चित करने के लिए चरणों को लागू करने से पहले। इस तरह, आप मूल बैकअप स्थिति को सुरक्षित रखते हैं, जो बाद में काम आ सकती है। मैं दृढ़ता से इस दृष्टिकोण से चिपके रहने की सलाह देता हूं।

एक पूर्ण बैकअप तैयार करने के लिए, विफलता के लिए निकटतम को चुनें, इसे पसंदीदा स्थान पर कॉपी करें, और निम्न आदेश निष्पादित करें:

mariabackup --prepare \
   --target-dir=data/backups/mariadb/COPY_D20210220

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

हम इसे तैयार . क्रियान्वित करके प्राप्त करते हैं प्रत्येक वृद्धिशील बैकअप के लिए कमांड जैसा कि नीचे दिखाया गया है:

mariabackup --prepare \
   --target-dir=/data/backups/mariadb/COPY_D20210220 \
   --incremental-dir=/data/backups/mariadb/D20210220_INC#

बैकअप प्रतिलिपि तैयार करने के बाद, हमें डेटाबेस उदाहरण को बंद करना होगा (प्रक्रिया)। साथ ही, हमें खाली करना चाहिए डेटाबेस निर्देशिका पुनर्स्थापना प्रक्रिया समाप्त करने से पहले। आप -प्रतिलिपि-वापस . के साथ या तो आदेश जारी कर सकते हैं विकल्प

mariabackup --copy-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

या – पीछे हटें . के साथ विकल्प:

mariabackup --move-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

बाद वाला कमांड कॉपी की गई निर्देशिका को डेटाबेस निर्देशिका में ले जाता है। मूल बैकअप को किसी अन्य स्थान पर कॉपी करना एक बुद्धिमान विकल्प है। अन्यथा, बैकअप खो जाएगा, क्योंकि अन्य स्थितियों और परिदृश्यों के लिए इसका उपयोग नहीं किया जा सकेगा।

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

तार्किक बैकअप से पुनर्प्राप्ति

अक्सर, हम तार्किक बैकअप का उपयोग करके डेटाबेस और/या तालिकाओं को पुनर्प्राप्त करते समय एक महत्वपूर्ण बिंदु को अनदेखा कर देते हैं। यह बिंदु max_allowed_packet . सेट कर रहा है सत्र का आकार (इसे विश्व स्तर पर सेट करना बुद्धिमानी हो सकती है) 1073741824 के अधिकतम मूल्य पर। यह सुनिश्चित करना आवश्यक है कि बड़े बफर और INSERT स्टेटमेंट क्लाइंट और सर्वर के बीच एक पैकेट में फिट हों। इससे पुनर्प्राप्ति समय कम होना चाहिए।

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

mysql -u backupuser -p backuppasswd  < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

यदि आपके पास बैकअप में शामिल कोई डेटाबेस नहीं है, जैसा कि अलग-अलग डेटाबेस बैकअप के साथ है, या आपको किसी अन्य डेटाबेस पर पुनर्स्थापना को पुनर्निर्देशित करने की आवश्यकता है, तो एक अलग कोड का उपयोग करें:

mysql -u backupuser -p backuppasswd  newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

डिस्क स्नैपशॉट के साथ पुनर्प्राप्ति

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

प्वाइंट-इन-टाइम रिकवरी

पॉइंट इन टाइम रिकवरी (PITR), जैसा कि नाम से ही स्पष्ट है, विफलता से पहले के समय के करीब डेटाबेस और तालिकाओं को पुनर्प्राप्त करने की एक विधि है। या, यदि दैनिक बैच प्रक्रिया विफल हो गई है और इसे फिर से निष्पादित करने की आवश्यकता है, तो आपके पास एकमात्र विकल्प भी है - PITR बैकअप पुनर्प्राप्ति करें।

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

चूंकि बिन-लॉग एक लेन-देन लॉग है और एक क्रम में बनाया गया है, इसलिए सभी लॉगफाइलों का बैकअप बनाना महत्वपूर्ण है। जहां तक PITR प्रक्रिया का सवाल है, यह असंभव है लॉगफाइल के बिना। इसके अलावा, बिन-लॉग रखरखाव और जीवन-चक्र को किसी भी पूर्ण और वृद्धिशील बैकअप के जीवन-चक्र का पालन करना चाहिए। इस प्रकार, सुनिश्चित करें कि केवल उन लॉग को शुद्ध करें जो बैकअप नीति में सबसे पुराने बैकअप से पुराने हैं।

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

PURGE BINARY LOGS TO 'mariadb-bin.000063';

दूसरा, यह पर्ज कमांड में रखे गए सबसे पुराने बैकअप की तारीख घोषित कर रहा है:

PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';

पुनर्प्राप्ति की तैयारी के लिए, हमें आवश्यक समय पर फिर से चलाने के लिए सभी आवश्यक कथनों को पुनः प्राप्त करने की आवश्यकता है। बैकअप शुरू होने के समय से लेकर आपके ठीक होने के समय तक उपलब्ध सभी बिन-लॉग्स को एकत्रित करें।

बैकअप समाप्त होने के समय से लेकर PITR समय तक लॉग सूची की जांच करके प्रारंभ करें:

mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql

फिर, अस्थायी फ़ाइलों की जांच करके सटीक लॉग पोजीशन ढूंढें जिन्हें आप लागू करना और उपयोग करना चाहते हैं। ये हैं –प्रारंभ-स्थिति और –स्टॉप-पोज़िशन जो कमांड में सटीक स्थिति निर्धारित करता है और mysqlbinlog . को फिर से निष्पादित करता है आदेश:

mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql

इस बिंदु पर, वसूली की प्रक्रिया शुरू हो गई है। यह या तो भौतिक या तार्किक बैकअप का उपयोग करता है, पूर्ण या वृद्धिशील।

final_temporary_PITR_file.sql लागू करके पुनर्प्राप्ति समाप्त करें MySQL क्लाइंट का उपयोग करना जैसा कि नीचे दिखाया गया है:

mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sql

हमने PITR पुनर्प्राप्ति को लॉग से निकटतम बिंदु तक विफलता होने के क्षण तक बैकअप और फिर से चलाए गए लेन-देन को पुनर्स्थापित करके पूरा कर लिया है।

कार्यक्षेत्र

MySQL और MariaDB में डेटाबेस डिज़ाइन और विकास, परीक्षण और रखरखाव के लिए, हम एक विंडोज़ एप्लिकेशन वर्कबेंच का उपयोग कर सकते हैं। यह लिनक्स पर भी काम करता है। इस एप्लिकेशन के साथ, उपयोगकर्ता डेटाबेस डिज़ाइन कर सकते हैं, मेटा डेटा देख और बदल सकते हैं, डेटा और मेटा डेटा स्थानांतरित कर सकते हैं, और बहुत कुछ कर सकते हैं। यह जोड़ने योग्य है कि कार्यक्षेत्र के बजाय MySQL के लिए dbForge Studio का उपयोग करना संभव है।

निष्कर्ष

कुल मिलाकर, हमने MySQL और MariaDB में उपलब्ध टूल और विधियों के साथ डेटाबेस बैकअप और पुनर्प्राप्ति तकनीकों पर संक्षेप में चर्चा की है और उन्हें चित्रित किया है।

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

PITR को सफलतापूर्वक निष्पादित करने के लिए, हमें बिन-लॉग सक्षम और उचित लॉग-प्रबंधन आवश्यकताओं की आवश्यकता है जगह पर।

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