Mysqldump एक क्लाइंट उपयोगिता है जिसका उपयोग MySQL डेटाबेस का तार्किक बैकअप करने के लिए किया जाता है। यह लोकप्रिय माइग्रेशन टूल MySQL के विभिन्न उपयोग मामलों के लिए उपयोगी है जैसे:
- डेटाबेस का बैकअप और पुनर्स्थापना।
- डेटा को एक सर्वर से दूसरे सर्वर पर माइग्रेट करना।
- विभिन्न प्रबंधित MySQL सेवा प्रदाताओं में डेटा माइग्रेट करना।
- MySQL के विभिन्न संस्करणों के बीच डेटा माइग्रेट करना।
Mysqldump स्रोत डेटाबेस ऑब्जेक्ट्स को पढ़कर और डंप फ़ाइल में संग्रहीत SQL कथनों का एक सेट उत्पन्न करके काम करता है। गंतव्य डेटाबेस सर्वर पर इन कथनों को फिर से चलाकर, मूल डेटा का पुनर्निर्माण किया जाता है। चूंकि यह मॉडल पूरे डेटाबेस को पढ़ने और फिर अनिवार्य रूप से पुनर्निर्माण का उपयोग करता है, डंप और रिस्टोर दोनों एक बड़े डेटाबेस के लिए समय लेने वाले ऑपरेशन हैं। यदि आप डंप या पुनर्स्थापना के दौरान त्रुटियों का सामना करते हैं तो यह प्रक्रिया बोझिल भी हो सकती है क्योंकि यह आपको समस्याओं को ठीक करने और संचालन को फिर से चलाने के लिए प्रेरित कर सकता है। यही कारण है कि डंप करने और गतिविधि बहाल करने से पहले अच्छी तरह से योजना बनाना महत्वपूर्ण है।
इस 2-भाग की ब्लॉग श्रृंखला में, हम कुछ सामान्य पहलुओं पर चर्चा करते हैं जिन्हें आपको एक सफल डंप सुनिश्चित करने और गतिविधि बहाल करने के लिए पहले से ही संभालना चाहिए। पहले भाग में, हम उन पूर्वापेक्षाओं पर ध्यान केंद्रित करते हैं जिन्हें आपको MySQL तालिका डेटा आयात करते समय ध्यान रखने की आवश्यकता होती है और दूसरे भाग में, हम इस बारे में बात करेंगे कि संग्रहीत प्रोग्राम ऑब्जेक्ट्स और दृश्यों के लिए आयात को कैसे प्रबंधित किया जाए।
1. जगह की ज़रूरतें
सबसे पहले, यह सुनिश्चित करना महत्वपूर्ण है कि आपके गंतव्य डेटाबेस वॉल्यूम में आयातित डेटा को रखने के लिए पर्याप्त स्थान है। विशेष रूप से, यदि आपके गंतव्य MySQL डेटाबेस पर बाइनरी लॉग सक्षम हैं, तो आपको सतर्क रहने की आवश्यकता है, क्योंकि डेटा आयात करते समय उत्पन्न बाइनरी लॉग डेटा के लगभग बराबर आकार ले सकते हैं। यदि आप अपने डेटा को एक सर्वर पर पुनर्स्थापित करना चाहते हैं और इसे दोहराया जाना चाहते हैं तो बाइनरी लॉग की आवश्यकता होती है। ऐसे मामलों में, स्रोत डेटाबेस के आकार के दोगुने से बड़े गंतव्य आकार की योजना बनाना एक अच्छा विचार है।
यह सुनिश्चित करना भी महत्वपूर्ण है कि जिस वॉल्यूम पर आप mysqldump आउटपुट फ़ाइल जेनरेट करते हैं, उस पर पर्याप्त स्थान उपलब्ध है। इन सावधानियों के बिना, आप लंबे समय तक चलने के बाद अपर्याप्त स्थान के कारण अपने डंप या पुनर्स्थापना को विफल होते हुए देख सकते हैं जो आपके उत्पादक समय और प्रयास का नुकसान है।
2. Sql_mode
MySQL सर्वर के लिए sql_mode सेटिंग्स SQL स्टेटमेंट सिंटैक्स और डेटा सत्यापन जांच निर्धारित करती हैं कि सर्वर संचालन के लिए करता है। यह सुनिश्चित करना महत्वपूर्ण है कि sql_mode स्रोत और गंतव्य के MySQL सर्वर एक दूसरे के साथ संगत हैं, या आपके द्वारा लिए गए डंप को पुनर्स्थापित करते समय आपको विफलताओं का सामना करना पड़ सकता है। आइए इसे एक उदाहरण के साथ प्रदर्शित करते हैं।
कहते हैं कि आपके स्रोत पर एक तालिका है जिसमें एक दिनांक स्तंभ है जिसमें प्रविष्टियां शून्य तिथियों के रूप में हैं:
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
सख्त मान लीजिए sql_mode (और NO_ZERO_DATE ) स्रोत पर अक्षम है, लेकिन गंतव्य पर सक्षम है - ऐसी पंक्तियों को पुनर्स्थापित करने से विफलता होगी जैसे:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
यदि आप अपने mysqldump के हिस्से के रूप में कॉम्पैक्ट विकल्प को सक्षम करके एक कॉम्पैक्ट डंप ले रहे हैं, तो आपको आमतौर पर ऐसी समस्याएं दिखाई देंगी।
यदि कॉम्पैक्ट अक्षम है (जो डिफ़ॉल्ट रूप से है) तो आपको इस समस्या का सामना नहीं करना पड़ेगा क्योंकि mysqldump डंप के हिस्से के रूप में निम्नलिखित सशर्त विवरण उत्पन्न करता है:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
इसका मतलब है कि पुनर्स्थापना के दौरान sql_mode 'NO_AUTO_VALUE_ON_ZERO' . पर सेट है तालिका डेटा को पुनर्स्थापित करने से पहले इसलिए पुनर्स्थापित करना ठीक है।
3. Unique_checks और Foreign_key_checks
डिफ़ॉल्ट रूप से (यदि आप -compact विकल्प का उपयोग नहीं करते हैं), mysqldump निम्नलिखित को भी सेट करता है:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
जैसा कि यहां बताया गया है, आप सत्र के दौरान विशिष्ट जांच को अस्थायी रूप से बंद करके पुनर्स्थापना कार्रवाई को गति दे सकते हैं। बड़ी तालिकाओं के लिए, यह बहुत सारी डिस्क I/O बचाता है क्योंकि InnoDB बैच में द्वितीयक अनुक्रमणिका रिकॉर्ड लिखने के लिए अपने परिवर्तन बफर का उपयोग कर सकता है।
यदि आपके पास FOREIGN KEY है आपकी तालिकाओं में बाधाएं, आप पुनर्स्थापना सत्र की अवधि के लिए विदेशी कुंजी जांच को बंद करके तालिका पुनर्स्थापना संचालन को गति दे सकते हैं:बड़ी तालिकाओं के लिए, यह बहुत सारी डिस्क I/O को बचा सकता है।
अक्षम करना FOREIGN_KEY_CHECKS पुनर्स्थापना ऑपरेशन के दौरान फोरगिन कुंजी बाधा जांच के कारण त्रुटियों से बचने में भी मदद मिलेगी। जब भी फोरगिन कुंजी बाधा वाली तालिका बनाई जाती है, तो MySQL अपेक्षा करता है कि मूल तालिका जिसे फोरगिन कुंजी द्वारा संदर्भित किया जाता है वह पहले से मौजूद है। यह एक समस्या है क्योंकि mysqldump उपयोगिता तालिकाओं को वर्णानुक्रम में डंप करती है। इसे प्रदर्शित करने के लिए एक उदाहरण लेते हैं।
स्रोत डेटाबेस पर, हमारे पास दो टेबल हैं:
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
तालिका ref_table एक विदेशी कुंजी बाधा है जो solution_table . का संदर्भ देती है . वर्णानुक्रम के आधार पर, mysqldump पहले ref_table . की सामग्री को डंप करता है . जब इसे पुनर्स्थापित करते समय फिर से चलाया जाता है, तो यह त्रुटि के साथ विफल हो जाएगा:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
‘ref_table’ के लिए टेबल स्टेटमेंट बनाते समय क्या होता है ।
संक्षेप में, यदि आप --compact निर्दिष्ट करते हैं, तो आपके सामने आने वाली समस्याओं से अवगत रहें mysqldump चलाते समय विकल्प।
4. Mysqldump चलाने के लिए आवश्यक विशेषाधिकार
एक डेटाबेस को डंप करने के लिए mysqldump द्वारा आवश्यक न्यूनतम विशेषाधिकार SELECT है उस डेटाबेस पर।
हालांकि, यदि आपके डेटाबेस में दृश्य हैं, तो आपको SHOW VIEW अनुमतियों की भी आवश्यकता होगी, क्योंकि mysqldump हमेशा डेटाबेस की तालिकाओं के साथ विचारों को डंप करता है। मान लीजिए आपके पास SHOW VIEW नहीं है अनुमतियाँ, तो mysqldump इसके साथ विफल हो जाएगा:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
एक अन्य रुचिकर बिंदु यह है कि यदि आपके डंपर के पास SELECT है केवल डेटाबेस की किसी विशेष तालिका पर अनुमतियाँ, mysqldump केवल उस विशेष तालिका के लिए डेटा डंप करेगा और स्वचालित रूप से किसी अन्य तालिका या दृश्य को अनदेखा कर देगा।
इसलिए कृपया सुनिश्चित करें कि mysqldump निष्पादित करने वाले उपयोगकर्ता के पास बाद में किसी भी आश्चर्य या विफलता से बचने के लिए सभी उपयुक्त विशेषाधिकार हैं।
|
5. Max_allowed_packet
mysql द्वारा संचालित सबसे बड़ा संचार पैकेट max_allowed_packet सेटिंग द्वारा निर्धारित किया जाता है . आयात के संदर्भ में, एक संचार पैकेट एक एकल SQL कथन होता है जो पुनर्स्थापना के दौरान MySQL सर्वर को भेजा जाता है या एक एकल पंक्ति जो क्लाइंट को डंप के दौरान भेजी जाती है।
max_allowed_packet का डिफ़ॉल्ट मान mysqldump के लिए 24MB है। यदि mysqldump इससे बड़ा पैकेट प्राप्त करता है, तो आप त्रुटि में भाग सकते हैं:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
इसलिए सुनिश्चित करें कि mysqldump max_allowed_packet के समान या बड़े मान का उपयोग करता है जो स्रोत MySQL इंस्टेंस पर कॉन्फ़िगर किया गया है।
विकल्प को फ्लैग के साथ निर्दिष्ट किया जा सकता है --max-allowed-packet=value mysqldump को लागू करते समय।
डंप को पुनर्स्थापित करते समय, सुनिश्चित करें कि max_allowed_packet आपके गंतव्य सर्वर का आकार डंप फ़ाइल से पैकेट प्राप्त करने के लिए काफी बड़ा है।
अन्यथा, डंप की पुनर्स्थापना के दौरान, आपको एक त्रुटि संदेश दिखाई देगा:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
यह त्रुटि थोड़ी भ्रामक हो सकती है क्योंकि आप सोच सकते हैं कि MySQL सर्वर बंद हो गया है या क्रैश हो गया है। लेकिन, इसका सीधा सा मतलब है कि सर्वर को इसके कॉन्फ़िगर किए गए आकार के max_allowed_packet से बड़े आकार का पैकेट प्राप्त हुआ है। . फिर से, सर्वोत्तम अभ्यास यह सुनिश्चित करना है कि max_allowed_packet आपके गंतव्य सर्वर के लिए मान स्रोत सर्वर के मान के समान है। यह भी एक महत्वपूर्ण सेटिंग है जिसे बाद में त्रुटियों का सामना करने के बजाय जांचा जा सकता है और उचित रूप से अग्रिम रूप से सेट किया जा सकता है।
mysqldump श्रृंखला के इस पहले भाग में, हमने बड़े MySQL डेटाबेस के लिए एक सफल डंप और पुनर्स्थापना संचालन के लिए पूर्वापेक्षाओं पर चर्चा की ताकि आपको कई प्रयासों और अनुत्पादक समय से बचने में मदद मिल सके।
अगले भाग में, हम आपके MySQL डेटाबेस से संग्रहीत प्रोग्राम और दृश्यों को आयात करने के सर्वोत्तम अभ्यासों पर चर्चा करेंगे।
