अधूरा मायस्कल्डम्प

Question

मैं एक डेटाबेस स्नैपशॉट बनाने के लिए mysqldump को चलाने की कोशिश कर रहा हूं, और मुझे पता चल रहा है कि यह बिना किसी त्रुटि के रिपोर्ट किए बिना बेतरतीब ढंग से मिडवे को रोक देगा। मेरा डेटाबेस अपेक्षाकृत छोटा है (लगभग 100MB) और InnoDB का उपयोग कर रहा है।

मैं इसे चला रहा हूं:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

बाहर निकलने की कोड रिपोर्ट की जाँच 0।

मेरा संस्करण है: mysqldump Ver 10.13 Distrib 5.1.52, redhat-linux-gnu (i386) के लिए

मैंने कुछ समान पोस्ट और यहां तक ​​कि एक आधिकारिक बग रिपोर्ट देखी है , लेकिन न तो समाधान लागू होते हैं।

पूर्ण डेटाबेस स्नैपशॉट लेने के लिए मुझे mysqldump कैसे मिलेगा?

संपादित करें: मेरा डेटाबेस वर्तमान में अमेज़ॅन के आरडीएस पर रहता है।

Comments

क्या पर्याप्त अनादर है? और क्या आपने देखा है कि टेबल पर कोई डीबी भ्रष्टाचार नहीं है?

क्या आपने --forceपरम को हटाने की कोशिश की है कि आपको क्या त्रुटि मिलती है? या --quick?

@ एड्रियन, हां, मेरे पास लगभग 10GB मुफ्त स्थान है, पर्याप्त से अधिक है। और हां, सभी टेबल ठीक हैं।

@ यज़मीर, हाँ, वही समस्या होती है।

Answer 1

यह max_allowed_packetदोनों क्लाइंट (यानी mysqldump) और सर्वर (यानी Amazon sDS) पर पर्याप्त रूप से सेट नहीं होने के साथ एक समस्या हो सकती है । मैं दोनों को 500M पर सेट करता हूं और लगता है कि समस्या ठीक हो गई है।

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

Answer 2

आपने कोशिश की है?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

यह सरल तरीका है जो मैं हमेशा बिना किसी समस्या के करता हूं। मूल रूप से इस तरह से डंप करने से आपको एक निश्चित समय पर सभी चीजें मिलती हैं (डेटा, ऑब्जेक्ट और कभी-कभी कीमती टिप्पणियां)।

Comments

उस कमांड को चलाने की कोशिश करते समय मुझे निम्नलिखित त्रुटि मिली:mysqldump: Got error: 1049: "Unknown database 'data'" when selecting the database

— एंडी

@ और अब आप इसके साथ कुछ गलत करते हैं। dev.mysql.com/doc/refman/5.7/en/… । मुझे लगता है कि "डेटा" बिल्कुल नहीं होना चाहिए।

— रुई मर्क

Answer 3

जहां तक ​​मैं समझता हूं कि mysql डॉक्स - सिंगल्स-ट्रांजेक्शन विफल हो जाएगा यदि आप डंपिंग करते समय टेबल पर एक रीड करते हैं। "--Force --single-transaction --quick" के बिना चलने पर क्या परिणाम होता है?

Comments

मुझे वही त्रुटि मिलती है।

— सेरिन

मुझे इस कथन का समर्थन करने के लिए दस्तावेज में कुछ भी नहीं मिला। AFAIK पढ़ता है और मेज पर लिखता है - जब सिंग्नल-लेन-देन का प्रदर्शन किया जाता है, तब समर्थन किया जाता है, लेकिन टेबल-स्ट्रक्चरिंग स्टेटमेंट (ALTER, CREATE, TRUNCATE, आदि) डंप के विफल होने या अप्रत्याशित डेटा देने का कारण हो सकता है। ( dev.mysql.com/doc/refman/5.7/en/… )

— कोड कमांडर

Answer 4

यह पूरी तरह से संभव है कि तालिका भ्रष्ट है। मेरा मतलब यह नहीं है कि डेटा और / या सूचकांक पृष्ठ क्षतिग्रस्त हैं। बहुत कुछ सरल हो सकता है जो टूट गया है।

मैंने हाल ही में एक स्लेव सर्वर पर एक बैकअप स्क्रिप्ट के साथ एक समस्या का अनुभव किया, जब मैंने कई डेटाबेस के समानांतर mysqldumped किया। डेटाबेस में से एक पर mysqldump चलाने से एक बहुत छोटा mysqldump निकला। DB में 80+ टेबल थे। हालांकि, डीबी में पांचवीं मेज पर mysqldump बंद हो गया। जब मैं SHOW CREATE TABLE tblname\Gस्लेव पर टेबल पर भागा , तो मुझे "टेबल नॉट फाउंड" की त्रुटि मिली। जब मैं SHOW CREATE TABLE tblname\Gमास्टर पर भागा , तो तालिका विवरण अपेक्षित रूप से प्रदर्शित हुआ।

जो हुआ वह थोड़ा पागल था: एक क्लाइंट ने टेबल को रिस्टोर करने के लिए कहा और एक इंजीनियर ने डिस्क बैकअप से इनोबीडी टेबल की .ibd फाइल को रिस्टोर किया। .Ibd फ़ाइल (जो 25 वर्ष की थी) की टेबलस्पेस आईडी ibdata1 (जो कि 28) में पंजीकृत टेबलस्पेस आईडी से मेल नहीं खाती थी।

मैंने गुलाम को छुपाने, मास्टर को खुश करने, और खरोंच से प्रतिकृति स्थापित करके समस्या को ठीक किया। सौभाग्य से, डेटा और इंडेक्स कुल 7GB हो गए। इस प्रकार rstore प्रक्रिया कोई बड़ी बात नहीं थी।

कहानी का नैतिक

बुनियादी समस्या यह है कि mysqldump जब टेबलस्पेस आईडी गलत है, तो एक InnoDB में त्रुटि की रिपोर्ट नहीं करता है। जब एक mysqldump खत्म हो जाता है और वर्णमाला के क्रम में हर तालिका को डंप नहीं करता है, तो यह इंगित करता है कि यह एक त्रुटि द्वारा समाप्त हो गया है और एक त्रुटि संदेश को प्रिंट किए बिना ऐसा किया है।

सुनिश्चित करने के लिए जाँच करें

• आप तालिका की संरचना का उपयोग करके प्रदर्शित कर सकते हैं SHOW CREATE TABLE
• आप INFORMATION_SCHEMA.TABLES की एक तालिका के बारे में सब कुछ क्वेरी कर सकते हैं

Answer 5

निम्नलिखित mysqldump और InnoDB पर केवल कुछ विचार-मंथन है:

कृपया InnoDB तालिका के विरुद्ध mysqldump के व्यवहार के बारे में सोचें। अगर आपके द्वारा डंप किए जा रहे टेबल से संबंधित किसी भी गंदे पृष्ठ में InnoDB बफर पूल है, तो उस टेबल के गंदे पेजों को डिस्क से बाहर निकालने से पहले डिस्क से फ्लश किया SELECT /* SQL_NO_CACHE */जा सकता है।

चूंकि आप अमेज़ॅन आरडीएस का उपयोग कर रहे हैं, इसलिए मेरा अनुभव यह है कि आपका डेटाबेस एक बहु-स्तरीय बुनियादी ढांचे में है (इस कथन को सही करने के लिए स्वतंत्र महसूस करें यदि मैं इस पर नज़र रखता हूं)। अन्य डेटाबेस एक साझा InnoDB बफर पूल, एक साझा मेटाडेटा फ़ाइल (ibdata1), और एक साझा टेबलस्पेस (ibdata1 अगर innodb_file_per_table अक्षम है) का उपयोग कर सकते हैं।

डेटाबेस के कुछ अतिरेक भी हो सकते हैं, जो MVCC को डेटाबेस के खिलाफ प्रभावित कर सकता है, भले ही यह एक छोटा डेटासेट हो।

आप अपने mysqldump सत्र में innodb_lock_wait_timeout (डिफ़ॉल्ट 50 सेकंड) को बढ़ाना चाहते हैं, यह देखने के लिए कि अमेजन आरडीएस पर इसका कोई प्रभाव है (या अमेज़ॅन ने इस सीमा को बढ़ाया है)। इसके अलावा, अलग-अलग तालिकाओं के साथ प्रयोग करके देखें।

UPDATE 2011-11-14 17:58 EDT

अपने DB सत्र के भीतर इसे निष्पादित करने का प्रयास करें (इसे दो मिनट में सेट करें):

SET innodb_lock_wait_timeout = 120;

Comments

innodb_lock_wait_timeout RDS पर एक स्थिर पैरामीटर है जिसे बदला नहीं जा सकता।

— सेरिन

@ केरिन: डॉक्स के अनुसार, आप इसे अपने सत्र में सेट कर सकते हैं।

— RolandoMySQLDBA

आपका क्या मतलब है "मेरा सत्र"? mysqldump किसी भी टाइमआउट को समायोजित करने के लिए कोई विकल्प नहीं सूचीबद्ध करता है।

— सेरिन

क्षमा करें, मैं इसे पीछे की ओर देख रहा था। मेरा कहने का मतलब Amazon RDS में innodb_lock_wait_timeout सेट करना है।

— RolandoMySQLDBA