MySQL 5.0 -> पर्नकोटा सर्वर 5.5 पुनर्संबंधित भंडारण के साथ निर्बाध प्रवासन

नमस्ते

मैं उत्पादन से लगभग बिना रुके MySQL 5.0 से Percona Server 5.5 के तहत एक कॉम्बैट डेटाबेस माइग्रेट करने के अपने अनुभव को साझा करना चाहता हूं।

मैं संक्षेप में वर्तमान राज्य के लिए हमारे आधार के विकास का वर्णन करूंगा

हमारा आधार प्राचीन है, कई MySQL उन्नयन से बचे। शुरुआत MySQL 3.x से हुई। जैसे ही लोड बढ़ता गया, पहले से ही MySQL 5.0 पर , हमने प्रतिकृति को कॉन्फ़िगर किया और पढ़ने के लिए एक और सर्वर कनेक्ट किया। तब हमने xtrabackup को शामिल किए बिना, मानक MySQL उपकरणों का उपयोग करते हुए यह किया - हमने साइटों पर मास्टर डंप और पोस्ट किए गए स्टब्स बनाने के समय सर्वर को पूरी तरह से अवरुद्ध कर दिया।

फिर अगली समस्या उत्पन्न हुई - डेटा वॉल्यूम पर जगह अंतरिक्ष से बाहर चलने लगी। प्लस इनबीडीबी भंडारण ऐतिहासिक रूप से एक ही फाइल में स्थित है। कई विकल्पों पर विचार किया गया है। ISCSI वॉल्यूम पर डेटाबेस रखने से शुरू करके और छापे में और अधिक कैपेसिटिव डिस्क को खींचने के साथ समाप्त होता है, उन्हें वॉल्यूम ग्रुप / लॉजिकल वॉल्यूम के साथ विस्तारित करना और फिर फ़ाइल सिस्टम का विस्तार करना।

एक अस्थायी विकल्प के रूप में, हमने VMWare vCloud ( ईमानदारी से नहीं! ) के तहत एक वर्चुअल मशीन से iSCSI वॉल्यूम कनेक्ट करने का निर्णय लिया। vCloud हमारे ठीक बगल में है।

हमने गुलाम पर एक प्रयोग के साथ शुरुआत की। प्रयोग सफल रहा, और कुछ समय के लिए दूसरे रीड-ओनली MySQL ने iSCSI वॉल्यूम पर स्टोरेज रखा।

वे आधार को पूरी तरह से बादल में ले जाने के बारे में गंभीरता से सोचने लगे

प्रयोग के रूप में, हमने vCloud में एक सर्वर को दूसरे रीड स्लेव के साथ जोड़ा। पहले गुलाम से सभी लोड को इसमें स्थानांतरित किया। प्रदर्शन के मामले में, वर्चुअल सर्वर एक अच्छे अंतर से जीता है। VCloud होस्ट से अधिक शक्तिशाली हार्डवेयर से प्रभावित। लोड वापस स्विच करें। वे सोचने लगे।

इस क्षण, एक अजीब रहस्यमय घटना घटी। वर्चुअल सर्वर पर लोड के साथ प्रयोग पूरा होने के कुछ घंटों बाद, डेटा सेंटर में एक दर्दनाक दुर्घटना हुई, जिसके परिणामस्वरूप कई सर्वर एक भौतिक दास सहित डी-एनर्जेट किए गए थे। भौतिक दास के iSCSI मात्रा पर स्थित रिले लॉग को कचरा मिला। प्रतिकृति रुक ​​गई है।

इस स्थिति में सबसे तार्किक कार्रवाई क्लाउड स्लेव पर स्विच हो रही थी, जो हमने किया।

इस प्रकार, हम पहले से ही vCloud में केवल एक पढ़ने-योग्य पैर थे। गुरु को घसीटना जरूरी था।

उन्होंने पेरकोना 5.5 को स्थानांतरित करने का फैसला किया, दो सर्वरों के लिए भी, लेकिन इनोबीडी स्टोरेज के सारणीबद्ध विभाजन के साथ।

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

मास्टर डंप प्राप्त करने के लिए, आपको 125 गीगाबाइट बेस को एक घंटे से अधिक समय तक लॉक करना होगा। यह युद्धक आधार पर अस्वीकार्य है। हमने xtrabackup का उपयोग करके मास्टर का बैकअप लेने का निर्णय लिया, परिणामी कलाकारों पर सर्वर बढ़ाएं, और मास्टर डंप को इससे हटा दें।

तो, सामग्री

• लोड के तहत दो पुराने MySQL-5.0 लड़ाकू सर्वर। हम उन्हें 5.0-मास्टर और 5.0-दास कहते हैं ।
• लोड, डेटा और प्रतिकृति के बिना अब तक दो नए मुकाबला पेरकोना-5.5 सर्वर। हम उन्हें 5.5-मास्टर और 5.5-दास कहेंगे।
• डंप डंपिंग के लिए एक मध्यवर्ती MySQL-5.0 सर्वर। चलो इसे 5.0-केनी कहते हैं ।

नए सर्वर पर टेबल में InnoDB भंडारण को विभाजित करने के लिए, आपको " innodb_file_per_table = 1 " विकल्प सेट करना होगा।

चूंकि यह एक बादल है, हम पांच मिनट में तीन लापता सर्वरों को आसानी से उठा सकते हैं।

एक न्यूनतम करने के लिए डाउनटाइम को कम करने के कार्यक्रम के भाग के रूप में, हमने नए मास्टर के साथ काम करने के लिए एप्लिकेशन को पुन: कॉन्फ़िगर नहीं करने का निर्णय लिया, लेकिन नए सर्वर पर पुराने मास्टर के आईपी ​​को बढ़ाएं। ऐसा करने के लिए, सभी क्लाइंट के लिए पुराने सर्वर का आईपी नए विज़ार्ड पर दिखाई देना चाहिए। हमारे मामले में, सभी पांच सर्वर एक ही सबनेट पर हैं, इसलिए इससे कोई समस्या नहीं है।

और अब - क्रियाओं का क्रम

• मास्टर बेस ( 5.0-मास्टर ) से, हम xtrabackup का उपयोग करके डंप को हटाते हैं :
  
  

  innobackupex --user=root --password=Yoo0edae ___ 

  
  यह याद रखना महत्वपूर्ण है कि आपके डेटाबेस में डेटा की बड़ी मात्रा MyISAM तालिकाओं में है, अब डेटाबेस को xtrabackup के अंतिमकरण के दौरान बंद कर दिया जाएगा, क्योंकि MyISAM तालिकाओं को अंतिम डेटाबेस लॉक के दौरान पूरी तरह से कॉपी किया जाता है। हमारे मामले में, व्यावहारिक रूप से कोई MyISAM डेटा नहीं है, इसलिए डेटाबेस केवल कुछ सेकंड के लिए बंद स्थिति में है।
• परिणामी डेटा निर्देशिका में एक फ़ाइल " xtrabackup_binlog_info " है - हम इसे बिनलॉग में स्थिति से याद करते हैं।
• परिणामी छाप 5.0-केनी पर कॉपी की गई है ( हमने 5.0-मास्टर पर एनएफएस के माध्यम से केनी ड्राइव को माउंट किया, और इसे गंतव्य निर्देशिका में इंगित किया जब xtrabackup ने डेटा निकाला , इसलिए 5.0-केनी पर डेटा xtxtackup कार्य के दौरान दिखाई दिया )। हम इसे वहां तैयार करते हैं :
  
  

   innobackupex --apply-log ____ 

  
  
• हम MySQL को रोकते हैं। हम MySQL डेटा के साथ डायरेक्टरी को साफ करते हैं, उसमें अपनी डली को कॉपी करते हैं:
  
  

   innobackupex --copy-back ____ 

  
  मैन्युअल रूप से कॉपी किया जा सकता है। फिर MySQL स्टोरेज में बैकअप प्रक्रिया से कुछ कचरा रहेगा। यदि आवश्यक हो, तो डेटा निर्देशिका पर सही स्वामी डालें।
• हम MySQL शुरू करते हैं। हम सुनिश्चित करते हैं कि कोई त्रुटि न हो।
• 5.0-केनी के साथ हम डंप हटाते हैं:
  
  

   mysqldump --all-databases > mysql.dump 

  
  
• 5.5-मास्टर को परिणामस्वरूप डंप की प्रतिलिपि बनाएँ। इसमें डालो:
  
  

   mysql < mysql.dump 

  
  
• MySQL को पुनरारंभ करें। हम लॉग में त्रुटियों के पहाड़ की प्रशंसा करते हैं। हम सर्किट को संस्करण 5.5 में अपग्रेड करते हैं:
  
  

   mysql_upgrade --force 

  
  
• MySQL को पुनरारंभ करें। लॉग साफ होना चाहिए।
• प्रतिकृति चालू करें, 5.5-मास्टर को 5.0-मास्टर बिनलॉग से कनेक्ट करें। ऐसा करने के लिए, पहले 5.0-मास्टर पर प्रतिकृति के लिए उपयोगकर्ता को जोड़ें (हर कोई सर्वर-आईडी , राइट के बारे में याद रखता है?):
  
  

   mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl_master_55' IDENTIFIED BY 'slavepass'; mysql> FLUSH PRIVILEGES; 

  
  जिसके बाद हम 5.5-मास्टर पर अनुरोध निष्पादित करते हैं:
  
  

   mysql> CHANGE MASTER TO MASTER_HOST='master_host_name', MASTER_USER='repl_master_55', MASTER_PASSWORD='slavepass', MASTER_LOG_FILE='recorded_log_file_name', MASTER_LOG_POS=recorded_log_position; mysql> START SLAVE; 

  
  MASTER_LOG_FILE और MASTER_LOG_POS का मान " xtrabackup_binlog_info " फ़ाइल से लिया गया है।
• हम सुनिश्चित करते हैं कि प्रतिकृति चली गई है:
  
  

   mysql> SHOW SLAVE STATUS\G 

  
  हमारा 5.5-मास्टर कुछ समय के लिए 5.0-मास्टर का दास होगा। 5.5-मास्टर पर बिनलोग को प्राप्त करने के लिए 5.0-मास्टर से अनुरोधों के लिए, विकल्प " लॉग-स्लेव-अपडेट = 1 " को 5.5-मास्टर पर सेट किया जाना चाहिए। डिफ़ॉल्ट रूप से, यह शून्य है, अर्थात बिनलॉग में केवल स्थानीय परिवर्तन होते हैं।
• Xtrabackup का उपयोग करके 5.5-मास्टर डंप से निकालें। डंप को 5.5-स्लेव में कॉपी करें।
• 5.5-स्लेव उठाएं, इसे 5.5-मास्टर बिनलॉग पर हुक करें।

कुल में, हमें चार सर्वर मिलते हैं: दो पुराने, लेकिन अभी भी MySQL 5.0 से लड़ रहे हैं, और वर्तमान डेटा के साथ दो नए Percona 5.5 ।

• पुराने 5.0-स्लेव से नए 5.5-स्लेव में पूरे रीड-ओनली लोड को स्विच करें। चूंकि 5.5-गुलाम को 5.5-मास्टर के साथ दोहराया जाता है, जो बदले में 5.0-मास्टर के साथ दोहराया जाता है, कोई भी कुछ भी नोटिस नहीं करता है। आधा काम किया जाता है - लोड का हिस्सा जो हमारे पास पहले से ही एक नए गुच्छा पर है।

मज़ा शुरू होता है। स्विच मास्टर । यहीं पर वापसी की बात है। इस क्षण से, हम मास्टर बेस के डाउनटाइम को नोट करते हैं।

• हम MySQL को 5.0-मास्टर पर रोकते हैं।
• हम यह सुनिश्चित करते हैं कि बिनलॉग का सारा डेटा 5.5-मास्टर पर है
• बिनलॉग से 5.5-मास्टर बुनना:
  
  

   mysql> RESET SLAVE ALL; 

  
  
• MySQL को 5.5-मास्टर पर रोकें
• 5.0-मास्टर पर हम नेटवर्क इंटरफ़ेस डालते हैं जिस पर डेटाबेस के साथ संचार किया जाता है, इस आईपी को उस सर्वर पर बढ़ाएं जिस पर हमारे पास 5.5-मास्टर है ।
• हम सुनिश्चित करते हैं कि arp टेबल अपडेट हो गया है।
• 5.5-मास्टर उठाएँ। सुनिश्चित करें कि MySQL नए आईपी पर सुन रहा है।
• हम डेटाबेस से लगातार-कनेक्ट का उपयोग करके एप्लिकेशन को पुनरारंभ करते हैं।

सब

हमारे मामले में, डाउनटाइम लगभग डेढ़ मिनट था। इस समय का अधिकांश समय 5.0-गुरु का था । सिद्धांत रूप में, डेटाबेस को रोकने से पहले InnoDB कैश को छोड़ने से डाउनटाइम को और भी कम करना संभव था।

vCloud ने अच्छा काम किया। जब अधिक शक्तिशाली हार्डवेयर और बहुत तेज़ डिस्क सबसिस्टम के कारण प्रदर्शन में काफी वृद्धि हुई है, क्योंकि बड़ी संख्या में भौतिक मीडिया द्वारा वर्चुअल डिस्क को "स्मियर" किया जाता है।