Mysqldump MySQL के लिए सबसे लोकप्रिय तार्किक बैकअप उपकरण है। यह MySQL वितरण में शामिल है, इसलिए यह सभी MySQL उदाहरणों पर उपयोग के लिए तैयार है।
तार्किक बैकअप, हालांकि, MySQL डेटाबेस का बैकअप लेने का सबसे तेज़ या सबसे अधिक स्थान-कुशल तरीका नहीं है, लेकिन भौतिक बैकअप पर उनका बहुत बड़ा लाभ है।
भौतिक बैकअप आमतौर पर सभी या कुछ भी प्रकार के बैकअप नहीं होते हैं। हालांकि Xtrabackup के साथ आंशिक बैकअप बनाना संभव हो सकता है (हमने इसे अपने पिछले ब्लॉग पोस्ट में से एक में वर्णित किया था), ऐसे बैकअप को पुनर्स्थापित करना मुश्किल और समय लेने वाला है।
मूल रूप से, यदि हम किसी एकल तालिका को पुनर्स्थापित करना चाहते हैं, तो हमें पूरी प्रतिकृति श्रृंखला को रोकना होगा और सभी नोड्स पर एक ही बार में पुनर्प्राप्ति करना होगा। यह एक प्रमुख मुद्दा है - इन दिनों आप शायद ही कभी सभी डेटाबेस को रोकने का जोखिम उठा सकते हैं।
एक अन्य समस्या यह है कि तालिका स्तर न्यूनतम ग्रैन्युलैरिटी स्तर है जिसे आप एक्स्ट्राबैकअप के साथ प्राप्त कर सकते हैं:आप एक तालिका को पुनर्स्थापित कर सकते हैं लेकिन आप इसके हिस्से को पुनर्स्थापित नहीं कर सकते। तार्किक बैकअप, हालांकि, SQL कथनों को चलाने के तरीके से बहाल किया जा सकता है, इसलिए इसे आसानी से एक चल रहे क्लस्टर पर किया जा सकता है और आप (हम इसे आसानी से कॉल नहीं करेंगे, लेकिन फिर भी) चुन सकते हैं कि कौन सा SQL कथन चलाना है ताकि आप कर सकें किसी तालिका का आंशिक पुनर्स्थापना करें।
आइए एक नजर डालते हैं कि वास्तविक दुनिया में यह कैसे किया जा सकता है।
mysqldump का उपयोग करके एकल MySQL तालिका को पुनर्स्थापित करना
शुरुआत में, कृपया ध्यान रखें कि आंशिक बैकअप डेटा का एक समान दृश्य प्रदान नहीं करते हैं। जब आप अलग-अलग तालिकाओं का बैकअप लेते हैं, तो आप इस तरह के बैकअप को समय पर किसी ज्ञात स्थिति में पुनर्स्थापित नहीं कर सकते (उदाहरण के लिए, प्रतिकृति दास को प्रावधान करने के लिए) भले ही आप बैकअप से सभी डेटा को पुनर्स्थापित कर दें। इसे हमारे पीछे रखते हुए, आगे बढ़ते हैं।
हमारे पास एक मालिक और एक गुलाम है:
डेटासेट में एक स्कीमा और कई टेबल शामिल हैं:
mysql> SHOW SCHEMAS;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
mysql> SHOW TABLES FROM sbtest;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest11 |
| sbtest12 |
| sbtest13 |
| sbtest14 |
| sbtest15 |
| sbtest16 |
| sbtest17 |
| sbtest18 |
| sbtest19 |
| sbtest2 |
| sbtest20 |
| sbtest21 |
| sbtest22 |
| sbtest23 |
| sbtest24 |
| sbtest25 |
| sbtest26 |
| sbtest27 |
| sbtest28 |
| sbtest29 |
| sbtest3 |
| sbtest30 |
| sbtest31 |
| sbtest32 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
32 rows in set (0.00 sec)अब, हमें बैकअप लेना होगा। ऐसे कई तरीके हैं जिनसे हम इस मुद्दे पर संपर्क कर सकते हैं। हम पूरे डेटासेट का लगातार बैकअप ले सकते हैं लेकिन यह सभी डेटा के साथ एक बड़ी, एकल फ़ाइल उत्पन्न करेगा। एकल तालिका को पुनर्स्थापित करने के लिए हमें उस फ़ाइल से तालिका के लिए डेटा निकालना होगा। यह निश्चित रूप से संभव है, लेकिन यह काफी समय लेने वाला है और यह बहुत अधिक मैनुअल ऑपरेशन है जिसे स्क्रिप्ट किया जा सकता है लेकिन यदि आपके पास उचित स्क्रिप्ट नहीं है, तो आपका डेटाबेस डाउन होने पर तदर्थ कोड लिखना और आप भारी दबाव में हैं जरूरी नहीं कि सबसे सुरक्षित विचार हो।
इसके बजाय हम बैकअप इस तरह तैयार कर सकते हैं कि प्रत्येक तालिका एक अलग फ़ाइल में संग्रहीत हो:
[email protected]:~/backup# d=$(date +%Y%m%d) ; db='sbtest'; for tab in $(mysql -uroot -ppass -h127.0.0.1 -e "SHOW TABLES FROM ${db}" | grep -v Tables_in_${db}) ; do mysqldump --set-gtid-purged=OFF --routines --events --triggers ${db} ${tab} > ${d}_${db}.${tab}.sql ; doneकृपया ध्यान दें कि हमने --set-gtid-purged=OFF सेट किया है। यदि हम इस डेटा को बाद में डेटाबेस में लोड कर रहे हैं तो हमें इसकी आवश्यकता है। अन्यथा MySQL @@GLOBAL.GTID_PURGED सेट करने का प्रयास करेगा, जो, सबसे अधिक संभावना है, विफल हो जाएगा। MySQL SET @@SESSION.SQL_LOG_BIN=0; जो निश्चित रूप से वह नहीं है जो हम चाहते हैं। यदि हम संपूर्ण डेटा सेट का लगातार बैकअप बनाना चाहते हैं और हम इसका उपयोग एक नए नोड के प्रावधान के लिए करना चाहते हैं, तो उन सेटिंग्स की आवश्यकता होती है। हमारे मामले में हम जानते हैं कि यह एक सुसंगत बैकअप नहीं है और ऐसा कोई तरीका नहीं है जिससे हम इससे कुछ भी पुनर्निर्माण कर सकें। हम केवल एक डंप उत्पन्न करना चाहते हैं जिसे हम मास्टर पर लोड कर सकते हैं और इसे दासों को दोहराने दे सकते हैं।
उस कमांड ने sql फाइलों की एक अच्छी सूची तैयार की जिसे प्रोडक्शन क्लस्टर में अपलोड किया जा सकता है:
[email protected]:~/backup# ls -alh
total 605M
drwxr-xr-x 2 root root 4.0K Mar 18 14:10 .
drwx------ 9 root root 4.0K Mar 18 14:08 ..
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest10.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest11.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest12.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest13.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest14.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest15.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest16.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest17.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest18.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest19.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest1.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest20.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest21.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest22.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest23.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest24.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest25.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest26.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest27.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest28.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest29.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest2.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest30.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest31.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest32.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest3.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest4.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest5.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest6.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest7.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest8.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest9.sqlजब आप डेटा को पुनर्स्थापित करना चाहते हैं, तो आपको केवल SQL फ़ाइल को मास्टर नोड में लोड करना होगा:
[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sqlडेटा को डेटाबेस में लोड किया जाएगा और सभी दासों को दोहराया जाएगा।
ClusterControl का उपयोग करके एकल MySQL तालिका को कैसे पुनर्स्थापित करें?
वर्तमान में ClusterControl केवल एक तालिका को पुनर्स्थापित करने का एक आसान तरीका प्रदान नहीं करता है, लेकिन इसे कुछ मैन्युअल क्रियाओं के साथ करना अभी भी संभव है। दो विकल्प हैं जिनका आप उपयोग कर सकते हैं। सबसे पहले, कम संख्या में तालिकाओं के लिए उपयुक्त, आप मूल रूप से शेड्यूल बना सकते हैं जहां आप एक-एक करके अलग-अलग तालिकाओं का आंशिक बैकअप करते हैं:
यहां, हम sbtest.sbtest1 तालिका का बैकअप ले रहे हैं। हम आसानी से sbtest2 तालिका के लिए एक और बैकअप शेड्यूल कर सकते हैं:
वैकल्पिक रूप से हम बैकअप कर सकते हैं और एक स्कीमा से डेटा को एक में डाल सकते हैं अलग फ़ाइल:
अब आप या तो फ़ाइल में हाथ से गुम डेटा ढूंढ सकते हैं, पुनर्स्थापित करें इस बैकअप को किसी अलग सर्वर पर या ClusterControl को करने दें:
आप सर्वर को चालू रखते हैं और आप उस डेटा को निकाल सकते हैं जो आप या तो mysqldump या SELECT… INTO OUTFILE का उपयोग करके पुनर्स्थापित करना चाहता था। ऐसा निकाला गया डेटा प्रोडक्शन क्लस्टर पर लागू होने के लिए तैयार होगा।
