अपने डेटाबेस को एक नए डेटासेंटर में माइग्रेट करना एक उच्च जोखिम और समय लेने वाली प्रक्रिया हो सकती है। डेटाबेस में स्थिति होती है, और वेब सर्वर, क्यू या कैश सर्वर की तुलना में माइग्रेट करना बहुत कठिन हो सकता है।
इस ब्लॉग पोस्ट में, हम आपको अपने डेटा को एक सेवा प्रदाता से दूसरे सेवा प्रदाता में माइग्रेट करने के बारे में कुछ सुझाव देंगे। प्रक्रिया कुछ हद तक हमारी पिछली पोस्ट के समान है कि कैसे MySQL को अपग्रेड किया जाए, लेकिन कुछ महत्वपूर्ण अंतर हैं।
MySQL प्रतिकृति या गैलेरा क्लस्टर?
किसी अन्य सेवा प्रदाता पर स्विच करना (उदाहरण के लिए, AWS से रैकस्पेस या कोलोकेटेड सर्वर से क्लाउड पर जाना) का अक्सर मतलब होता है कि कोई व्यक्ति समानांतर में एक नया बुनियादी ढांचा तैयार करेगा, इसे पुराने बुनियादी ढांचे के साथ सिंक करेगा और फिर उस पर स्विच करेगा। उन्हें कनेक्ट और सिंक करने के लिए, आप MySQL प्रतिकृति का लाभ उठाना चाह सकते हैं।
यदि आप गैलेरा क्लस्टर का उपयोग कर रहे हैं, तो अपने गैलेरा नोड्स को किसी भिन्न डेटासेंटर में ले जाना आसान हो सकता है। हालाँकि, ध्यान दें कि पूरे क्लस्टर को अभी भी एक ही डेटाबेस के रूप में माना जाना है। इसका मतलब यह है कि आपकी उत्पादन साइट WAN पर गैलेरा क्लस्टर को खींचते समय शुरू की गई अतिरिक्त विलंबता से पीड़ित हो सकती है। गैलेरा और ऑपरेटिंग सिस्टम दोनों में नेटवर्क सेटिंग्स को ट्यून करके प्रभाव को कम करना संभव है, लेकिन प्रभाव को पूरी तरह से समाप्त नहीं किया जा सकता है। यदि विलंबता प्रभाव स्वीकार्य नहीं है, तो पुराने और नए क्लस्टर के बीच एसिंक्रोनस MySQL प्रतिकृति सेट करना भी संभव है।
सुरक्षित कनेक्टिविटी सेट करना
MySQL प्रतिकृति अनएन्क्रिप्टेड है, और इसलिए WAN पर उपयोग करने के लिए सुरक्षित नहीं है। यह सुनिश्चित करने के कई तरीके हैं कि आपका डेटा सुरक्षित रूप से स्थानांतरित हो जाएगा। आपको जांच करनी चाहिए कि क्या आपके मौजूदा बुनियादी ढांचे और आपके नए सेवा प्रदाता के बीच वीपीएन कनेक्शन स्थापित करना संभव है। अधिकांश प्रदाता (उदाहरण के लिए रैकस्पेस और एडब्ल्यूएस दोनों) ऐसी सेवा प्रदान करते हैं - आप वर्चुअल प्राइवेट नेटवर्क के माध्यम से अपने "क्लाउडी" हिस्से को अपने मौजूदा डेटासेंटर से जोड़ सकते हैं।
यदि, किसी कारण से, यह समाधान आपके लिए काम नहीं करता है (हो सकता है कि इसके लिए ऐसे हार्डवेयर की आवश्यकता हो, जिसकी आपके पास पहुंच नहीं है), तो आप VPN बनाने के लिए सॉफ़्टवेयर का उपयोग कर सकते हैं - उनमें से एक OpenVPN होगा। यह उपकरण आपके डेटा केंद्रों के बीच एन्क्रिप्टेड कनेक्शन सेटअप करने के लिए अच्छी तरह से काम करेगा।
यदि OpenVPN एक विकल्प नहीं है, तो यह सुनिश्चित करने के और भी तरीके हैं कि प्रतिकृति को एन्क्रिप्ट किया जाएगा। उदाहरण के लिए, आप पुराने और नए डेटासेंटर के बीच एक सुरंग बनाने के लिए SSH का उपयोग कर सकते हैं, और 3306 पोर्ट को वर्तमान MySQL स्लेव (या मास्टर) से नए नोड में अग्रेषित कर सकते हैं। यह बहुत ही सरल तरीके से किया जा सकता है जब तक आपके पास मेजबानों के बीच SSH कनेक्टिविटी है:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &उदाहरण के लिए:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &अब, आप 127.0.0.1:3307
. का उपयोग करके रिमोट सर्वर से कनेक्ट कर सकते हैं$ mysql -P3307 -h 127.0.0.1यह प्रतिकृति के लिए समान रूप से काम करेगा, बस मास्टर_होस्ट के लिए 127.0.0.1 और मास्टर_पोर्ट के लिए 3307 का उपयोग करना याद रखें
अंतिम लेकिन कम से कम आप एसएसएल का उपयोग करके अपनी प्रतिकृति को एन्क्रिप्ट कर सकते हैं। यह पिछला ब्लॉग पोस्ट बताता है कि यह कैसे किया जा सकता है और प्रतिकृति प्रदर्शन पर इसका किस प्रकार का प्रभाव हो सकता है।
यदि आपने दोनों डेटा केंद्रों में गैलेरा प्रतिकृति का उपयोग करने का निर्णय लिया है, तो उपरोक्त सुझाव यहां भी लागू होते हैं। जब एसएसएल की बात आती है, तो हमने पहले ब्लॉग किया था कि गैलेरा प्रतिकृति ट्रैफ़िक को कैसे एन्क्रिप्ट किया जाए। अधिक संपूर्ण समाधान के लिए, आप क्लाइंट अनुप्रयोगों और किसी भी प्रबंधन/निगरानी अवसंरचना से सभी डेटाबेस कनेक्शन को एन्क्रिप्ट करना चाह सकते हैं।
नई अवसंरचना की स्थापना
एक बार आपके पास कनेक्टिविटी हो जाने के बाद, आपको नए बुनियादी ढांचे का निर्माण शुरू करना होगा। उसके लिए, आप शायद xtrabackup या mariabackup का उपयोग करेंगे। माइग्रेशन को MySQL अपग्रेड के साथ जोड़ना आकर्षक हो सकता है, आखिरकार आप नए स्थान पर नया वातावरण स्थापित कर रहे हैं। हम ऐसा करने की अनुशंसा नहीं करेंगे। एक नए बुनियादी ढांचे में माइग्रेट करना अपने आप में काफी महत्वपूर्ण है इसलिए इसे एक और बड़े बदलाव के साथ मिलाने से जटिलता और जोखिम बढ़ जाता है। यह अन्य बातों के लिए भी सही है - आप परिवर्तनों के लिए चरण-दर-चरण दृष्टिकोण अपनाना चाहते हैं। केवल चीजों को एक-एक करके बदलने से ही आप परिवर्तनों के परिणामों को समझ सकते हैं, और वे आपके कार्यभार को कैसे प्रभावित करते हैं - यदि आपने एक निश्चित समय में एक से अधिक परिवर्तन किए हैं, तो आप सुनिश्चित नहीं हो सकते हैं कि किसी दिए गए के लिए कौन जिम्मेदार है (नया) ) व्यवहार जो आपने देखा है।
जब आपके पास एक नया MySQL इंस्टेंस है और नए डेटासेंटर में चल रहा है, तो आपको इसे पुराने डेटासेंटर में नोड से स्लेव करना होगा - यह सुनिश्चित करने के लिए कि दोनों डेटासेंटर में डेटा सिंक में रहेगा। जब आप अंतिम कटओवर के लिए खुद को तैयार करेंगे तो यह आसान हो जाएगा। यह सुनिश्चित करने का भी एक अच्छा तरीका है कि नया वातावरण आपके लेखन भार को संभाल सके।
अगला कदम नए स्थान में एक पूर्ण स्टेजिंग इंफ्रास्ट्रक्चर का निर्माण करना और परीक्षण और बेंचमार्क करना होगा। यह एक बहुत ही महत्वपूर्ण कदम है जिसे छोड़ना नहीं चाहिए - यहां समस्या यह है कि आपको, डीबीए के रूप में, अपने बुनियादी ढांचे की क्षमता को समझना होगा। जब आप प्रदाता बदलते हैं, तो चीजें भी बदल जाती हैं। नए हार्डवेयर/वीएम तेज या धीमे हैं। प्रति उदाहरण कम या ज्यादा स्मृति है। आपको फिर से यह समझने की जरूरत है कि आप जिस हार्डवेयर का उपयोग करने जा रहे हैं उसमें आपका कार्यभार कैसे फिट होगा। इसके लिए आप शायद पेरकोना प्लेबैक या पीटी-लॉग-प्लेयर का उपयोग स्टेजिंग सिस्टम पर वास्तविक जीवन के कुछ प्रश्नों को फिर से चलाने के लिए करेंगे। आप प्रदर्शन का परीक्षण करना चाहेंगे और सुनिश्चित करेंगे कि यह उस स्तर पर है जो आपके लिए स्वीकार्य है। आप अपनी नई रिलीज़ पर चलने वाले सभी मानक स्वीकृति परीक्षण भी करना चाहते हैं - बस यह पुष्टि करने के लिए कि सब कुछ ठीक है और चल रहा है। सामान्य तौर पर, सभी एप्लिकेशन इस तरह से बनाए जाने चाहिए कि वे हार्डवेयर कॉन्फ़िगरेशन और वर्तमान सेटअप पर निर्भर न हों। लेकिन हो सकता है कि कुछ छूट गया हो और आपका ऐप कुछ ऐसे कॉन्फिग ट्वीक या हार्डवेयर समाधानों पर निर्भर हो सकता है जो आपके पास नए परिवेश में नहीं हैं।
अंत में, एक बार जब आप अपने परीक्षणों से खुश हो जाते हैं, तो आप उत्पादन के लिए तैयार बुनियादी ढांचे का निर्माण करना चाहेंगे। ऐसा करने के बाद, आप अंतिम सत्यापन के लिए कुछ केवल-पढ़ने के लिए परीक्षण चलाना चाह सकते हैं। कटओवर से पहले यह अंतिम चरण होगा।
कटओवर
उन सभी परीक्षणों के बाद और बुनियादी ढांचे को उत्पादन-तैयार समझे जाने के बाद, अंतिम चरण पुराने बुनियादी ढांचे से यातायात में कटौती करना है।
विश्व स्तर पर, यह एक जटिल प्रक्रिया है, लेकिन जब हम डेटाबेस स्तर को देख रहे हैं, तो यह कमोबेश मानक विफलता के समान है - ऐसा कुछ जो आपने अतीत में कई बार किया होगा। हमने इसे पहले की पोस्ट में विवरण में कवर किया था, संक्षेप में चरण हैं:ट्रैफ़िक को रोकें, सुनिश्चित करें कि यह रुक गया है, एप्लिकेशन को नए डेटासेंटर में ले जाने के लिए प्रतीक्षा करें (DNS रिकॉर्ड बदलते हैं या क्या नहीं), यह सुनिश्चित करने के लिए कुछ धूम्रपान परीक्षण करें सब अच्छा लग रहा है, लाइव हो जाओ, थोड़ी देर के लिए बारीकी से निगरानी करें।
इस कटओवर के लिए कुछ डाउनटाइम की आवश्यकता होगी, जैसा कि हम देख सकते हैं। समस्या यह सुनिश्चित करने के लिए है कि हमारे पास पुरानी साइट और नई साइट पर लगातार स्थिति है। यदि हम इसे बिना डाउनटाइम के करना चाहते हैं, तो हमें मास्टर-मास्टर प्रतिकृति स्थापित करने की आवश्यकता होगी। इसका कारण यह है कि जैसे-जैसे हम DNS को रीफ़्रेश करते हैं और पुरानी साइट से सत्रों को नई साइट पर ले जाते हैं, दोनों सिस्टम एक ही समय में उपयोग में रहेंगे - जब तक कि सभी सत्र नई साइट पर पुनर्निर्देशित नहीं हो जाते। इस बीच, नई साइट पर किसी भी परिवर्तन को पुरानी साइट पर प्रतिबिंबित करने की आवश्यकता है।
गैलेरा क्लस्टर का उपयोग करना, जैसा कि इस ब्लॉग पोस्ट में वर्णित है, दोनों साइटों के बीच डेटा को सिंक में रखने का एक तरीका भी हो सकता है।
हम जानते हैं कि यह डेटा माइग्रेशन प्रक्रिया का एक बहुत ही संक्षिप्त विवरण है। उम्मीद है, यह आपको एक अच्छी दिशा में इंगित करने के लिए पर्याप्त होगा और आपको यह पहचानने में मदद करेगा कि आपको कौन सी अतिरिक्त जानकारी देखने की आवश्यकता है।
