MyISAM से InnoDB में रूपांतरण को तेज करना

Question

मेरे पास उत्पादन में एक MySQL 1.5 जीबी MyISAM-table (1.0 जीबी डेटा, 0.5 जीबी इंडेक्स) है जो मैं इनो डीबी में परिवर्तित करने जा रहा हूं।

चूंकि तालिका का उत्पादन में उपयोग किया जाता है, इसलिए मैं जितना संभव हो सके डाउनटाइम बनाना चाहता हूं।

मेरे सवालों का:

• MySQL विन्यास विकल्प आदेश ALTER TABLE table_name ENGINE=InnoDB; तेजी लाने के लिए में समायोजित किया जाना चाहिए क्या?

• MyISAM से InnoDB तक उत्पादन डेटाबेस तालिका के रूपांतरण को तेज़ करने के लिए अन्य चाल का उपयोग कैसे किया जा सकता है?

Answer 1

• एक बड़ी innodb_buffer_pool_size (2GB या अधिक) की स्थापना
• खोल का उपयोग कर कमांड
• वृद्धि innodb_log_file_size (256 एमबी)
• एक्स समानांतर सूत्र में बदलने की मेज करें अपने पुराने MyISAM डेटा/सूचकांक फ़ाइलें preread, जहां X रूपांतरण केवल (innodb_doublewrite = 0, innodb_flush_log_at_trx_commit = 0)

के लिए

अन्य छोटे तोड़ मरोड़ अपने सर्वर पर सीपीयू कोर के मात्रा है

जितना संभव हो सके innodb_buffer_pool_size सेट करना innodb टेबल निर्माण को गति देने का सामान्य तरीका है - आपका डेटासेट ऐसा लगता है कि यह 2 जीबी innodb बफर पूल के अंदर फिट हो सकता है, इसलिए किसी भी सभ्य 64 बिट सर्वर को इसकी अनुमति देनी चाहिए। तालिका प्रकार बदलना = innodb डंप + reimport समाधान से भी तेज है, और समानांतर में चलाने के लिए आसान है।

यह भी सुनिश्चित करें कि आपने innodb_log_file_size को 5 एमबी से 128 या 256 एमबी के डिफ़ॉल्ट से बढ़ा दिया है। इसके साथ सावधान रहें, और इसे एक पुराने शट डाउन की आवश्यकता है + पुराने ib_logfile * को मिटा दें।

यदि आपके सर्वर में 8 जीबी रैम की तरह कुछ है, और आप mysql के 64 बिट संस्करण चलाते हैं तो मैं 2 जीबी innodb_buffer_pool का सुझाव दूंगा, और आप डाउनटाइम बंद करने से पहले पुरानी MYD और MYI फ़ाइलों को भी पूर्ववत कर सकते हैं, ताकि वे असली काम शुरू होने पर ओएस के पेज कैश में होगा।

यदि आप मामूली tweaks के लिए भी जाते हैं, तो कृपया ध्यान रखें कि रूपांतरण (एक और छोटा डाउनटाइम) के बाद आपको अपने डेटा को सुरक्षित रखने के बाद उन्हें पूर्ववत करने की आवश्यकता है, मुझे संदेह है कि वे इस तरह के एक छोटे डेटासेट के लिए इसके लायक हैं।

शुभकामनाएं।

Answer 2

आप एक तेजी से (हालांकि कुछ हद तक लो-फाई) समाधान के बाद कर रहे हैं, तो आप बस पाठ फ़ाइल (mysqldump के माध्यम से) में डेटा निर्यात कर सकता है, उसके एवज में पाठ फ़ाइल में InnoDB के लिए तालिका प्रकार बदलने और उसके बाद डेटा दोबारा आयात करें।

उस ने कहा, आपको कोई समस्या नहीं होने के लिए एक अलग डेटाबेस में आयात करके इसका परीक्षण करना होगा।

Answer 3

तालिका केवल लिखने के लिए पहुंच योग्य नहीं होगी; पढ़ता है ALTER की अवधि के लिए पुरानी MyISAM तालिका तक पहुंच जारी रहेगा।

गंभीरता से, 1.5 जी तालिका का पुनर्निर्माण लंबे समय तक नहीं लेना चाहिए, यदि आपका ऐप डाउनटाइम की मात्रा बर्दाश्त नहीं कर सकता है, तो आपके पास कुछ एचए सिस्टम पहले से ही होना चाहिए जिसे आप ऐसा करने के लिए उपयोग कर सकते हैं।संभवतः आपकी तकनीकी सहायता टीम डाउनटाइम के बारे में उपयोगकर्ताओं को बताने और पर्याप्त चेतावनी देने के लिए एक नोटिस दे सकती है, आप इसे दिन/सप्ताह के शांत समय पर करेंगे (हम आमतौर पर रविवार को एक अच्छा समय पाने के लिए पाते हैं, लेकिन यह भिन्न हो सकता है आपके पास मुस्लिम देशों में बहुत से ग्राहक हैं)

आप यह पता लगा सकते हैं कि उसी कॉन्फ़िगरेशन और spec की गैर-उत्पादन प्रणाली पर डेटा के उसी आकार के साथ तालिका में कितना समय लगेगा, जो कि आप प्रदर्शन परीक्षण के लिए निस्संदेह है।

Answer 4

pt-online-schema-change का उपयोग करके आपकी समस्या अप्रासंगिक होगी। पीटी-ऑनलाइन-स्कीमा-चेंज एक कमांड लाइन उपकरण है जो इस समस्या को हल करने के लिए Percona (तर्कसंगत रूप से दुनिया में शीर्ष MySQL परामर्श) द्वारा डिज़ाइन किया गया है। यह आपको किसी भी तालिका पर या तो लिखने या लिखने के बिना किसी भी तालिका पर अलर्ट स्टेटमेंट करने की अनुमति देता है, यदि आप कहते हैं कि आप अपने वास्तविक लक्ष्य की संभावना है तो आप उत्पादन में इस रूपांतरण को तेज करने की कोशिश कर रहे हैं।

Percona टूलकिट स्थापित करने के बाद, आप बस अपने O/S खोल में निम्न आदेश चला जाएगा:

$ pt-online-schema-change h=your_host.com,t=your_db.your_target_table --alter "ENGINE=InnoDB"