मुझे यकीन नहीं है कि यह सुपरयूसर में पोस्ट किया जाना चाहिए या नहीं, क्योंकि हम वर्कबेंच में निर्मित माइग्रेशन विज़ार्ड का उपयोग कर रहे हैं, कृपया मुझे यह बताएं कि क्या यह प्रश्न ले जाना चाहिए।MySQL डेटाबेस माइग्रेशन डेटा अनुपलब्ध
उद्देश्य
हम एक और करने के लिए और के बाद से MySQL Workbench एक प्रवासन जादूगर कहा जाता समारोह में बनाया गया है हमने सोचा कि हम यह विस्थापित करने के लिए हमारे प्रमुदित रास्ते पर जाना होगा एक सर्वर से एक डेटाबेस स्थानांतरण की प्रक्रिया में वर्तमान में कर रहे हैं। हमारे पास 16 अलग-अलग डेटाबेस स्कीमा हैं जिन्हें अलग-अलग आकारों के साथ माइग्रेट किया जाना चाहिए (सबसे छोटा 3 एमबी और सबसे बड़ा 76 जीबी)।
समस्या
हम बड़े लोगों आकार मध्यम कि 14.7 जीबी पर बैठता है और ठीक से प्रारंभ होता है में से एक की ओर पलायन करने की कोशिश कर के साथ शुरू किया, लेकिन बाद में इसे सफलतापूर्वक कि एक में तालिकाओं के आधे माइग्रेट कर लिया है हम त्रुटि मिलती है " MySQL सर्वर रुक गया है"। यह सुनिश्चित करने के बाद कि कनेक्शन स्थिर है और इसे केबल से कनेक्ट किया गया है (हो सकता है कि यह वायरलेस सिग्नल जो गिरा दिया गया हो?) और पूर्ण विशेषाधिकार सुनिश्चित किया और माइग्रेशन के लिए रूट उपयोगकर्ता का उपयोग किया, हमें अभी भी "सर्वर चला गया है" त्रुटि मिलती है।
हमने फिर छोटे डेटाबेस के साथ प्रयास किया जो ठीक काम करता है, इसलिए हमने सोचा कि यह एक टाइम-आउट मुद्दा हो सकता है। हमने टाइमआउट सेटिंग्स को हटाने का प्रयास किया लेकिन हमें अभी भी बड़े डेटाबेस के लिए एक ही त्रुटि मिलती है। वास्तविक किकर वह है जिसे हम वर्तमान में अनुभव कर रहे हैं।
जब हमने 150 एमबी डेटाबेस पर यह कोशिश की तो माइग्रेशन विज़ार्ड फिर किसी भी त्रुटि या चेतावनियों के बिना माइग्रेशन को सही ढंग से पूरा करता है। जिज्ञासा से बाहर मैंने निम्नलिखित कोड
SELECT table_name AS "Table",
round(((data_length + index_length)/1024/1024), 2) "Size in MB"
FROM information_schema.TABLES
WHERE table_schema = "TableName"
ORDER BY "Table";
यह सुनिश्चित करने के लिए कि तालिका आकार सही हैं। हमारे आश्चर्य के लिए, हमारे स्रोत डेटाबेस में तालिकाओं का योग 150 एमबी कहता है, लेकिन लक्ष्य डेटाबेस में योग 94 एमबी कहता है।
प्रश्न (रों)
क्या कुछ अन्य कारणों के रूप में हो सकता है कारण है कि हम समय बाहर और विशेषाधिकारों से अलग "सर्वर दूर चला गया है" त्रुटि मिलती है? माइग्रेशन विज़ार्ड का कहना है कि माइग्रेशन चेतावनियों या त्रुटियों के बिना सफल हो गया लेकिन वास्तविकता में केवल 60% डेटा माइग्रेट किया गया था? क्या माइग्रेशन विज़ार्ड पर भरोसा नहीं किया जा सकता है या यह टेबल आकार क्वेरी है जिसे विश्वसनीय नहीं किया जाना चाहिए? क्या हम इस बारे में पूरी तरह गलत हैं, यानी, क्या आप डेटाबेस को माइग्रेट करने का एक और अधिक स्थिर तरीका सुझाते हैं?
यदि आवश्यक हो तो मुझे अधिक जानकारी प्रदान करने में खुशी होगी।
संपादित करें:
MySQL संस्करण: 5.1.41 (उबंटू)
हम भी हर स्कीमा में हर तालिका में पंक्तियों की संख्या की जाँच कर ली और जब तक सबसे सही हैं, कुछ गलत बढ़ाएं। यह वह जगह है जहां डेटा असंगतता खेल में आती है। 150 एमबी/9 4 एमबी उदाहरण में 25 टेबल हैं। इन 25 तालिकाओं में से 23 सही हैं और 2 नहीं हैं। स्रोत में, तालिकाओं में से एक में 2.57 मिलियन पंक्तियां हैं लेकिन इनमें से केवल 1.5 मिलियन लक्ष्य तालिका में समाप्त होती हैं।
संपादित करें 2:
समान क्वेरी चल रहा है फिर अब मुझे 150 का 94 दिया है, 150 के 8, 150 के 24 और अब चौथी बार यह पूरे डेटाबेस चले गए। मैं अनुमान लगा रहा हूं कि यह मुद्दा कहीं और स्थित है लेकिन मेरे जीवन के लिए क्यों नहीं पता चल सकता है। 150 एमबी डेटा माइग्रेट करने में 92 मिनट लग गए।Extrapolating जो मुझे 75 जीबी डेटाबेस माइग्रेट करने के लिए लगभग एक महीने दे देंगे - कुछ स्पष्ट रूप से सही नहीं है।
यह एक समय की समस्या की तरह दिखता है, इंटरैक्टिव टाइमआउट के लिए वर्तमान मूल्य क्या है और उस सत्र में या my.cnf में प्रतीक्षा समय क्या है? क्या आपने 0 (अनंत) दोनों को सेट करने का परीक्षण किया था? –
हमने my.cnf में देखा लेकिन इंटरैक्टिव या प्रतीक्षा टाइमआउट की तरह दिखने वाले किसी भी पैरामीटर को नहीं मिला। हम किस विशिष्ट पैरामीटर की तलाश में हैं? इसके साथ अपना समय लेने के लिए धन्यवाद। – MagneTism
[इंटरएक्टिव_टाउटआउट] (http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_interactive_timeout) 28800 पर डिफ़ॉल्ट है जो 8 घंटे है। –