क्या आप दुनिया के सबसे लोकप्रिय ओपन-सोर्स डेटाबेस के साथ शुरुआत करना चाहते हैं, और सोच रहे हैं कि आपको अपनी MySQL होस्टिंग कैसे सेटअप करनी चाहिए? अमेज़ॅन आरडीएस के लिए बहुत सारे डिफ़ॉल्ट, जब MySQL Azure क्लाउड पर असाधारण रूप से अच्छा प्रदर्शन करता है। जबकि Microsoft Azure एक प्रबंधित समाधान, Azure डेटाबेस प्रदान करता है, समाधान की कुछ प्रमुख सीमाएँ हैं जिनके बारे में आपको अपने MySQL परिनियोजन को माइग्रेट करने से पहले पता होना चाहिए। इस पोस्ट में, हम Azure पर MySQL को होस्ट करने के सर्वोत्तम तरीके की रूपरेखा तैयार करते हैं, जिसमें प्रबंधित समाधान, इंस्टेंस प्रकार, उच्च उपलब्धता प्रतिकृति, बैकअप और डिस्क प्रकार शामिल हैं जिनका उपयोग आपके क्लाउड डेटाबेस प्रदर्शन को अनुकूलित करने के लिए किया जाता है।
MySQL DBaaS vs. Self-Managed MySQL
स्वयं-प्रबंधन और एक MySQL डेटाबेस-ए-ए-सर्विस (DBaaS) समाधान के बीच वजन करते समय विचार करने वाली पहली बात यह है कि आपके पास कौन से आंतरिक संसाधन उपलब्ध हैं। यदि आप इसे पढ़ रहे हैं, तो आप पहले से ही उत्पादन परिनियोजन को बनाए रखने से जुड़े परिचालन कार्यों की भयावहता को जानते हैं, लेकिन एक त्वरित पुनर्कथन के लिए, प्रावधान, विप्रोविजनिंग, मास्टर-स्लेव कॉन्फ़िगरेशन, बैकअप, स्केलिंग, अपग्रेड, लॉग रोटेशन, ओएस पैचिंग है। , और कुछ नाम रखने के लिए निगरानी।
एक आंतरिक MySQL विशेषज्ञ, या आपके एप्लिकेशन आकार के आधार पर DBA की एक टीम, निश्चित रूप से आपके लिए आपके संगठन के साथ इन्हें संभाल सकती है, लेकिन सवाल यह बन जाता है कि आप अपनी टीम के प्रयासों को कहां केंद्रित करना चाहते हैं। . कई लोग इन समय लेने वाले कार्यों को स्वचालित करने के लिए MySQL DBaaS में जाने का निर्णय लेते हैं ताकि वे अपने एप्लिकेशन डेटाबेस के विकास और अनुकूलन पर अधिक ध्यान केंद्रित कर सकें। एक अच्छा उदाहरण धीमी क्वेरी विश्लेषण होगा। जबकि लगभग हर DBaaS समस्या प्रश्नों की पहचान करने में मदद करने के लिए एक MySQL स्लो क्वेरी एनालाइज़र टूल प्रदान करता है, इस कार्य के लिए अभी भी मानव कौशल और अंतर्ज्ञान की आवश्यकता होती है ताकि यह निर्धारित किया जा सके कि उनके एप्लिकेशन प्रदर्शन को प्रभावित करने वाले उन प्रश्नों को कैसे अनुकूलित किया जाए।
चाहे आप एक स्टार्टअप कंपनी हों या एक फॉर्च्यून 500 व्यवसाय, आप पाएंगे कि कई संगठन अपने DBA के समय को अनुकूलित करने के लिए DBaaS का लाभ उठाने का विकल्प चुनते हैं, जबकि समान व्यवसाय प्रकार और आकार आंतरिक स्व-प्रबंधन के साथ रहना भी चुनें। कई उद्यम व्यवसायों के लिए, निर्णय काफी हद तक अनुकूलन और नियंत्रण के लिए आता है। यही कारण है कि हम Azure डेटाबेस, या इसके AWS प्रतियोगी, Amazon RDS के लिए डिफ़ॉल्ट होने के प्रति सावधानी बरतते हैं, क्योंकि वे आपको MySQL सुपरयूज़र एक्सेस या यहां तक कि SSH को आपकी मशीनों तक पहुंचने की अनुमति नहीं देते हैं। इसके अतिरिक्त, आपके परिनियोजन सेटअप को अनुकूलित करने की क्षमता अत्यधिक सीमित है, जैसे कि इंस्टेंस प्रकार, रैम, डिस्क आकार, या आईओपीएस जिसका आप उपयोग कर सकते हैं। आप नीचे उपयोग करने के लिए सर्वोत्तम इंस्टेंस प्रकारों और डिस्क के बारे में अधिक जानेंगे, और आप शीर्ष चार प्रबंधित MySQL समाधान, स्केलग्रिड, कंपोज़, एज़्योर डेटाबेस और अमेज़ॅन आरडीएस के लाभों और सीमाओं को देखने के लिए इस MySQL प्रदाता तुलना को देख सकते हैं।
उच्च उपलब्धता परिनियोजन
यदि आप उत्पादन में परिनियोजन कर रहे हैं, तो आपको हमेशा MySQL को मास्टर-स्लेव परिनियोजन के रूप में सेटअप करना चाहिए। स्टैंडअलोन परिनियोजन बिना किसी प्रतिकृति के एक एकल नोड है, और वास्तव में इसका उपयोग केवल विकास या परीक्षण वातावरण के लिए किया जाना चाहिए। मास्टर-स्लेव परिनियोजन के साथ, आप उच्च उपलब्धता को कॉन्फ़िगर करने में सक्षम होते हैं, इसलिए यदि आपका एक नोड नीचे चला जाता है, तो आप शून्य डाउनटाइम वाले दास के लिए विफल हो सकते हैं। यह आमतौर पर या तो 3-नोड मास्टर-स्लेव-स्लेव या 2+1 नोड मास्टर-स्लेव-कोरम के रूप में सेटअप होता है। कोरम का उपयोग करने का लाभ यह है कि यह एक कम लागत वाला विकल्प है, लेकिन नकारात्मक पक्ष यह है कि आपके पास केवल 2 डेटा-असर वाले नोड हैं क्योंकि अन्य सर्वोत्तम विफलता पाठ्यक्रम निर्धारित करने के लिए कोरम नोड के रूप में कार्य करता है। यदि आपका एप्लिकेशन स्लेव से पढ़ने में सक्षम है, तो आपको रीड स्केलिंग करने की आवश्यकता है ताकि वे न्यूनतम अंतराल के साथ क्लस्टर वॉल्यूम से समान डेटा लौटाएं।
Azure Cloud पर MySQL को होस्ट करने का सबसे अच्छा तरीका ट्वीट करने के लिए क्लिक करें
MySQL मास्टर-स्लेव कॉन्फ़िगरेशन का उपयोग करते समय, हम डेटा अतिरेक के साथ आपकी डेटा अखंडता को बेहतर बनाने के लिए सेमीसिंक्रोनस प्रतिकृति सेट करने की अनुशंसा करते हैं। यह सुनिश्चित करता है कि जब कोई कमिट सफलतापूर्वक वापस आता है, तो डेटा मास्टर और स्लेव दोनों में मौजूद होता है, इसलिए डेटासेंटर के नीचे जाने की स्थिति में, आपका MySQL मास्टर बिना किसी डेटा हानि के एक दास के लिए विफल हो सकता है। आप इसे एसिंक्रोनस या सेमीसिंक्रोनस प्रतिकृति के साथ कर सकते हैं, और इसके बारे में हमारे MySQL उच्च उपलब्धता समझाया - भाग II ब्लॉग पोस्ट में अधिक जान सकते हैं।
तो, हम Azure पर MySQL के लिए उच्च उपलब्धता को कैसे कॉन्फ़िगर कर सकते हैं? हमें अपने दास उदाहरणों को विभिन्न Azure उपलब्धता क्षेत्रों (AZ) में वितरित करने की आवश्यकता है। इसलिए, हम यह सुनिश्चित करना चाहते हैं कि हम एक ऐसा Azure क्षेत्र चुनें जिसमें कम से कम 3 AZ हों, प्रत्येक उदाहरण को एक अलग AZ में रखते हुए। हम ऐसा इसलिए करते हैं क्योंकि उपलब्धता की गारंटी AZ में है, इसलिए यदि 1 ज़ोन नीचे चला जाता है, तो आपका एप्लिकेशन डेटाबेस अभी भी अन्य 2 AZ के माध्यम से ऑनलाइन रहने में सक्षम है। उपलब्धता क्षेत्र Azure के लिए काफी नए हैं, इसलिए यदि आप ऐसे क्षेत्र में काम कर रहे हैं जो AZ की पेशकश नहीं करता है, तो आपके पास उपलब्धता सेट का उपयोग करने का विकल्प है। ये AZ की तुलना में थोड़े कमजोर हैं, लेकिन सुनिश्चित करें कि आप संभावित आउटेज से बचाने के लिए विभिन्न डोमेन और रैक पर तैनात हैं। सभी क्षेत्रों में परिनियोजित करने का विकल्प भी है, लेकिन यह एक अधिक जटिल सेटअप है इसलिए हम अनुशंसा करते हैं कि लागू करने से पहले चर्चा करने के लिए संपर्क करें।
Azure Virtual Networks
अपने डेटाबेस को इंटरनेट से सुरक्षित रखने का सबसे अच्छा तरीका यह है कि इसे एक निजी सबनेट में तैनात किया जाए ताकि यह सुनिश्चित हो सके कि यह खुला नहीं है। Azure वर्चुअल नेटवर्क (VNET) के उपयोग के माध्यम से सेटअप करना आसान बनाता है जिसे आपके MySQL सर्वर के लिए कॉन्फ़िगर किया जा सकता है। MySQL के लिए Azure VNET के साथ, आप अपने सर्वर, इंटरनेट और यहां तक कि अपने ऑन-प्रिमाइसेस निजी क्लाउड नेटवर्क के बीच सुरक्षित संचार स्थापित करने में सक्षम हैं। ये आम तौर पर एक ही नेटवर्क पर संचार करने के लिए कॉन्फ़िगर किए गए हैं, लेकिन यदि आपको एक से अधिक क्षेत्रों को जोड़ने की आवश्यकता है, तो आप वर्चुअल नेटवर्क पीयरिंग के माध्यम से संचार करने के लिए कई VNET बना सकते हैं।
इसके अतिरिक्त, आप IP श्वेतसूची से निपटने के बिना नेटवर्क सुरक्षा समूह (NSG) नियमों के माध्यम से अपने MySQL अभिगम नियंत्रण का प्रबंधन कर सकते हैं। यह MySQL के लिए Azure डेटाबेस के माध्यम से उपलब्ध नहीं है, लेकिन VNET और NSG दोनों को Azure पर हमारी MySQL ब्रिंग योर ओन क्लाउड (BYOC) योजनाओं के माध्यम से कॉन्फ़िगर किया जा सकता है, जहाँ आप अपने स्वयं के क्लाउड खाते के माध्यम से अपने क्लस्टर होस्ट करने में सक्षम होते हैं।
Azure इंस्टेंस प्रकार
विचार करने का एक अन्य महत्वपूर्ण पहलू सार्वजनिक क्लाउड में आपके MySQL इंस्टेंस का प्रदर्शन है। Azure क्लाउड कई उदाहरण प्रकार प्रदान करता है जिनका उपयोग आपके MySQL होस्टिंग के लिए किया जा सकता है, जिसमें Es2 v3, Ds2, v2 और Ls4 शामिल हैं।
हम अनुशंसा करते हैं कि मेमोरी अनुकूलित इंस्टेंस प्रकारों के साथ शुरू करें क्योंकि डेटाबेस को बहुत अधिक RAM की आवश्यकता होती है और सर्वोत्तम प्रदर्शन के लिए संभव सबसे तेज़ डिस्क गति की तलाश में हैं। Es2 श्रृंखला आमतौर पर अधिकांश अनुप्रयोगों के लिए MySQL वर्कलोड के लिए एक अच्छा प्रारंभिक बिंदु है। वहां से, आप यह देखने के लिए कुछ प्रदर्शन परीक्षण कर सकते हैं कि क्या आपको अधिक CPU की आवश्यकता है, इस मामले में, संतुलित इंस्टेंस प्रकार या CPU-गहन इंस्टेंस प्रकार आपकी MySQL आवश्यकताओं को बेहतर ढंग से पूरा कर सकते हैं, जैसे Dv3 इंस्टेंस प्रकार। आपके प्रदर्शन परीक्षण यह भी दिखा सकते हैं कि आपको अधिक I/O (इनपुट/आउटपुट) की आवश्यकता है, आप डिस्क-गहन आवृत्ति प्रकार पर जा सकते हैं।
यदि आप अगले 1-3 वर्षों के लिए अपने MySQL क्लाउड प्रदाता के रूप में Azure का लाभ उठाने की योजना बनाते हैं और काफी सुसंगत परिनियोजन कॉन्फ़िगरेशन बनाए रखते हैं, तो आप आरक्षित उदाहरणों पर भी विचार कर सकते हैं। ये अनिवार्य रूप से प्रीपेड इंस्टेंस हैं जो आपको अपने MySQL होस्टिंग के लिए काफी लागत बचत प्राप्त करने की अनुमति देते हैं। औसतन, आप एक वर्ष के आरक्षित उदाहरणों के लिए लगभग 20% से 30% और 3 वर्ष के आरक्षित उदाहरणों पर 40% से 50% की बचत कर सकते हैं।
Azure डिस्क प्रकार
जब आपके MySQL परिनियोजन के लिए Azure डिस्क प्रकार चुनने की बात आती है, तो आपको पहला निर्धारण यह करना होगा कि क्या प्रबंधित बनाम अप्रबंधित डिस्क के साथ जाना है। अप्रबंधित डिस्क एज़्योर द्वारा प्रदान की जाने वाली लीगेसी डिस्क हैं जहां आपको संग्रहण खाता सेट करना होता है, अपनी डिस्क को संग्रहण खाते में मैप करना होता है, और उस संग्रहण खाते के लिए IOPS उपयोग और सीमाओं की निगरानी करनी होती है। हम प्रबंधित डिस्क का उपयोग करने की अत्यधिक अनुशंसा करते हैं, और यदि आप अभी भी अप्रबंधित डिस्क के साथ परिनियोजित कर रहे हैं, तो आपको प्रबंधित डिस्क पर जाने पर विचार करना चाहिए।
MySQL Dev/Test Environments:Standard Disks
Azure के माध्यम से कई प्रबंधित डिस्क प्रकार उपलब्ध हैं, डिफ़ॉल्ट मानक डिस्क हैं। मानक डिस्क 500 IOPS (प्रति सेकंड इनपुट/आउटपुट संचालन) का समर्थन कर सकते हैं और विकास और परीक्षण संचालन के लिए अच्छे हैं क्योंकि उन्हें गतिशील रूप से आकार दिया जा सकता है, लेकिन MySQL उत्पादन परिनियोजन के लिए उपयोग नहीं किया जाना चाहिए।
MySQL उत्पादन परिनियोजन:प्रीमियम डिस्क
आपके MySQL उत्पादन सर्वर के लिए, हम Azure प्रीमियम डिस्क का लाभ उठाने की अत्यधिक अनुशंसा करते हैं। प्रीमियम डिस्क की एक विस्तृत विविधता है जिसे आप चुन सकते हैं। प्रत्येक प्रीमियम डिस्क के लिए, आप सबसे अच्छा आकार चुन सकते हैं, और प्रत्येक आकार अलग-अलग प्रावधानित IOPS के साथ आता है, ताकि आप अपनी एप्लिकेशन आवश्यकताओं के लिए सबसे उपयुक्त एक का चयन कर सकें।
MySQL उत्पादन परिनियोजन:स्थानीय SSD
Azure Local SSD प्रीमियम डिस्क के लिए एक उच्च-प्रदर्शन विकल्प हैं, जो आमतौर पर बड़े क्लस्टर के लिए सबसे उपयुक्त होते हैं। स्थानीय एसएसडी बहुत अधिक I/O प्रदर्शन प्रदान करते हैं, और Azure में सबसे अच्छा थ्रूपुट प्रदान करते हैं। लेकिन, उनके पास एक खामी है कि वे अल्पकालिक डिस्क हैं, स्थायी स्टोर नहीं हैं, इसलिए यदि आप इंस्टेंस को रोकते हैं, तो डेटा चला जाता है। हम Ls v2 श्रृंखला की अनुशंसा करते हैं जो बहुत तेज़ हैं, लेकिन सावधानी बरतें कि CPU वास्तव में कमजोर है जो मशीन की बाधाओं का कारण बन सकता है।
Azure पर MySQL बैकअप
Azure पर अपने MySQL डेटा का बैकअप लेने का सबसे अच्छा तरीका प्रबंधित डिस्क स्नैपशॉट का उपयोग करना है। स्नैपशॉट डिस्क के समय संस्करण में केवल-पढ़ने के लिए बिंदु है। इन बैकअप को पढ़ा जा सकता है, कॉपी किया जा सकता है या हटाया जा सकता है, लेकिन ध्यान दें कि इन्हें संशोधित नहीं किया जा सकता है। पूर्ण बैकअप करना एक अच्छा विचार है, इसलिए यदि आपको कभी भी MySQL डेटाबेस को पुनर्प्राप्त करने की आवश्यकता होती है, तो आपके सभी डेटाबेस, उपयोगकर्ता और सेटिंग्स का बैकअप लिया जाता है। अपने बैकअप स्नैपशॉट को एन्क्रिप्ट करना भी एक अच्छा विचार है ताकि बैकअप को केवल उसी मशीन पर पुनर्स्थापित किया जा सके जिसमें बैकअप लिया गया था।
आपके MySQL बैकअप के परिणामस्वरूप अतिरिक्त Azure डेटा संग्रहण शुल्क लगेगा, जब तक कि आप स्केलग्रिड पर हमारी समर्पित होस्टिंग योजनाओं जैसे Azure समाधान पर एक सभी समावेशी MySQL का लाभ नहीं उठा रहे हैं। लागतों को नियंत्रित करने के लिए, एक अनुकूलन शेड्यूल के माध्यम से अपने बैकअप को स्वचालित करना एक अच्छा विचार है जो आपको अपने बैकअप की आवृत्ति, बनाए रखने के लिए बैकअप की अधिकतम संख्या और आपके बैकअप लक्ष्य को कॉन्फ़िगर करने की अनुमति देता है। यह निश्चित रूप से आपको यह सुनिश्चित करने में भी मदद करता है कि आपके उत्पादन परिनियोजन में किसी भी डेटा हानि के मामले में आपके MySQL डेटा का नियमित रूप से बैकअप लिया जाता है ताकि आप हाल के बैकअप के साथ जल्दी से ठीक हो सकें।
यदि आपके पास Azure पर MySQL को होस्ट करने के सर्वोत्तम तरीके के बारे में कोई प्रश्न हैं, तो हमें नीचे एक टिप्पणी दें या support@scalegrid पर हमसे संपर्क करें। आईओ आप अपने परिनियोजन के प्रदर्शन को बेहतर बनाने के लिए पूरी तरह से प्रबंधित MySQL सेवा का लाभ उठाने के लाभों का पता लगाने के लिए 30-दिन का निःशुल्क परीक्षण भी शुरू कर सकते हैं।
