क्लाउड में MySQL - Amazon RDS के पेशेवरों और विपक्ष

अपने डेटा को सार्वजनिक क्लाउड सेवा में ले जाना एक बड़ा निर्णय है। सभी प्रमुख क्लाउड विक्रेता क्लाउड डेटाबेस सेवाएं प्रदान करते हैं, जिसमें MySQL के लिए Amazon RDS शायद सबसे लोकप्रिय है।

इस ब्लॉग में, हम इस पर करीब से नज़र डालेंगे कि यह क्या है, यह कैसे काम करता है, और इसके पेशेवरों और विपक्षों की तुलना करें।

आरडीएस (रिलेशनल डाटाबेस सर्विस) एक अमेज़ॅन वेब सेवा की पेशकश है। संक्षेप में, यह एक सेवा के रूप में एक डेटाबेस है, जहां अमेज़ॅन आपके डेटाबेस को तैनात और संचालित करता है। यह डेटाबेस सॉफ़्टवेयर के बैकअप और पैचिंग के साथ-साथ उच्च उपलब्धता जैसे कार्यों का ध्यान रखता है। कुछ डेटाबेस आरडीएस द्वारा समर्थित हैं, हम यहां मुख्य रूप से MySQL में रुचि रखते हैं - अमेज़ॅन MySQL और मारियाडीबी का समर्थन करता है। औरोरा भी है, जो अमेज़ॅन का MySQL का क्लोन है, विशेष रूप से प्रतिकृति और उच्च उपलब्धता के क्षेत्र में सुधार हुआ है।

RDS के माध्यम से MySQL परिनियोजित करना

आइए RDS के माध्यम से MySQL के परिनियोजन पर एक नज़र डालें। हमने MySQL को चुना और फिर हमें चुनने के लिए कुछ परिनियोजन पैटर्न के साथ प्रस्तुत किया गया।

मुख्य विकल्प है - क्या हम उच्च उपलब्धता चाहते हैं या नहीं? औरोरा को भी बढ़ावा दिया जाता है।

अगला डायलॉग बॉक्स हमें कस्टमाइज़ करने के लिए कुछ विकल्प देता है। आप कई MySQL संस्करणों में से एक चुन सकते हैं - कई 5.5, 5.6 और 5.7 संस्करण उपलब्ध हैं। डेटाबेस इंस्टेंस - आप किसी दिए गए क्षेत्र में उपलब्ध विशिष्ट इंस्टेंस आकारों में से चुन सकते हैं।

अगला विकल्प एक बहुत ही महत्वपूर्ण विकल्प है - क्या आप मल्टी-एजेड परिनियोजन का उपयोग करना चाहते हैं या नहीं? यह सब उच्च उपलब्धता के बारे में है। यदि आप मल्टी-एजेड परिनियोजन का उपयोग नहीं करना चाहते हैं, तो एक एकल इंस्टेंस स्थापित किया जाएगा। विफलता के मामले में, एक नया काता जाएगा और इसके डेटा की मात्रा को इसमें वापस कर दिया जाएगा। इस प्रक्रिया में कुछ समय लगता है, जिसके दौरान आपका डेटाबेस उपलब्ध नहीं होगा। बेशक, आप दासों का उपयोग करके और उनमें से एक को बढ़ावा देकर इस प्रभाव को कम कर सकते हैं, लेकिन यह एक स्वचालित प्रक्रिया नहीं है। यदि आप स्वचालित उच्च उपलब्धता चाहते हैं, तो आपको मल्टी-एजेड परिनियोजन का उपयोग करना चाहिए। क्या होगा कि दो डेटाबेस इंस्टेंस बनाए जाएंगे। एक आपको दिखाई दे रहा है। दूसरा उदाहरण, एक अलग उपलब्धता क्षेत्र में, उपयोगकर्ता को दिखाई नहीं देता है। यह एक छाया प्रति के रूप में कार्य करेगा, सक्रिय नोड के विफल होने पर यातायात को संभालने के लिए तैयार है। यह अभी भी एक सही समाधान नहीं है क्योंकि यातायात को असफल उदाहरण से छाया में बदलना पड़ता है। हमारे परीक्षणों में, फेलओवर करने में ~45s का समय लगा, लेकिन जाहिर है, यह उदाहरण के आकार, I/O प्रदर्शन आदि पर निर्भर हो सकता है। लेकिन यह गैर-स्वचालित विफलता से बहुत बेहतर है जहां केवल दास शामिल हैं।

अंत में, हमारे पास भंडारण सेटिंग्स हैं - प्रकार, आकार, पीआईओपीएस (जहां लागू हो) और डेटाबेस सेटिंग्स - पहचानकर्ता, उपयोगकर्ता और पासवर्ड।

अगले चरण में, कुछ और विकल्प उपयोगकर्ता इनपुट की प्रतीक्षा कर रहे हैं।

हम चुन सकते हैं कि इंस्टेंस कहां बनाया जाना चाहिए:वीपीसी, सबनेट, क्या यह सार्वजनिक रूप से उपलब्ध होना चाहिए या नहीं (जैसा कि - आरडीएस इंस्टेंस को एक सार्वजनिक आईपी सौंपा जाना चाहिए), उपलब्धता क्षेत्र और वीपीसी सुरक्षा समूह। फिर, हमारे पास डेटाबेस विकल्प हैं:बनाया जाने वाला पहला स्कीमा, पोर्ट, पैरामीटर और विकल्प समूह, चाहे मेटाडेटा टैग स्नैपशॉट में शामिल किए जाने चाहिए या नहीं, एन्क्रिप्शन सेटिंग्स।

अगला, बैकअप विकल्प - आप अपने बैकअप कब तक रखना चाहते हैं? आप उन्हें कब लेना चाहेंगे? समान सेटअप रखरखाव से संबंधित है - कभी-कभी अमेज़ॅन प्रशासकों को आपके आरडीएस इंस्टेंस पर रखरखाव करना पड़ता है - यह एक पूर्वनिर्धारित विंडो के भीतर होगा जिसे आप यहां सेट कर सकते हैं। कृपया ध्यान दें, रखरखाव विंडो के लिए कम से कम 30 मिनट नहीं चुनने का कोई विकल्प नहीं है, इसलिए उत्पादन पर मल्टी-एजेड इंस्टेंस होना वास्तव में महत्वपूर्ण है। रखरखाव के परिणामस्वरूप नोड पुनरारंभ हो सकता है या कुछ समय के लिए उपलब्धता की कमी हो सकती है। मल्टी-एजेड के बिना, आपको उस डाउनटाइम को स्वीकार करना होगा। मल्टी-एजेड परिनियोजन के साथ, विफलता होती है।

अंत में, हमारे पास अतिरिक्त निगरानी से संबंधित सेटिंग्स हैं - क्या हम इसे सक्षम करना चाहते हैं या नहीं?

RDS का प्रबंधन

इस अध्याय में हम MySQL RDS को प्रबंधित करने के तरीके पर करीब से नज़र डालेंगे। हम वहां उपलब्ध हर विकल्प के माध्यम से नहीं जाएंगे, लेकिन हम अमेज़ॅन द्वारा उपलब्ध कराई गई कुछ सुविधाओं पर प्रकाश डालना चाहेंगे।

स्नैपशॉट

MySQL RDS स्टोरेज के रूप में EBS वॉल्यूम का उपयोग करता है, इसलिए यह विभिन्न उद्देश्यों के लिए EBS स्नैपशॉट का उपयोग कर सकता है। बैकअप, दास - सभी स्नैपशॉट पर आधारित हैं। आप मैन्युअल रूप से स्नैपशॉट बना सकते हैं या आवश्यकता पड़ने पर उन्हें स्वचालित रूप से लिया जा सकता है। यह ध्यान रखना महत्वपूर्ण है कि ईबीएस स्नैपशॉट, सामान्य रूप से (न केवल आरडीएस उदाहरणों पर), I/O संचालन में कुछ ओवरहेड जोड़ता है। यदि आप स्नैपशॉट लेना चाहते हैं, तो अपने I/O प्रदर्शन में गिरावट की अपेक्षा करें। जब तक आप बहु-एजेड परिनियोजन का उपयोग नहीं करते हैं, अर्थात। ऐसे मामले में, "छाया" उदाहरण का उपयोग स्नैपशॉट के स्रोत के रूप में किया जाएगा और उत्पादन आवृत्ति पर कोई प्रभाव दिखाई नहीं देगा।

बैकअप

बैकअप स्नैपशॉट पर आधारित होते हैं। जैसा कि ऊपर उल्लेख किया गया है, जब आप एक नया उदाहरण बनाते हैं तो आप अपने बैकअप शेड्यूल और प्रतिधारण को परिभाषित कर सकते हैं। बेशक, आप बाद में "संशोधित उदाहरण" विकल्प के माध्यम से उन सेटिंग्स को संपादित कर सकते हैं।

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

आरडीएस में एक अन्य विकल्प पॉइंट-इन-टाइम रिकवरी है - बहुत महत्वपूर्ण विशेषता, किसी के लिए भी एक आवश्यकता जिसे अपने डेटा की अच्छी देखभाल करने की आवश्यकता है। यहां चीजें अधिक जटिल और कम उज्ज्वल हैं। शुरुआत के लिए, यह ध्यान रखना महत्वपूर्ण है कि MySQL RDS उपयोगकर्ता से बाइनरी लॉग छुपाता है। आप कुछ सेटिंग्स और सूची निर्मित बिनलॉग बदल सकते हैं, लेकिन आपके पास उन तक सीधी पहुंच नहीं है - पुनर्प्राप्ति के लिए उनका उपयोग करने सहित कोई भी ऑपरेशन करने के लिए, आप केवल UI या CLI का उपयोग कर सकते हैं। यह आपके विकल्पों को सीमित करता है कि अमेज़ॅन आपको क्या करने की अनुमति देता है, और यह आपको अपने बैकअप को नवीनतम "रिस्टोरेबल टाइम" तक पुनर्स्थापित करने की अनुमति देता है, जिसकी गणना 5 मिनट के अंतराल में की जाती है। इसलिए, यदि आपका डेटा 9:33a पर हटा दिया गया है, तो आप इसे केवल 9:30 a पर राज्य में पुनर्स्थापित कर सकते हैं। पॉइंट-इन-टाइम रिकवरी उसी तरह काम करती है जैसे स्नैपशॉट को पुनर्स्थापित करना - एक नया इंस्टेंस बनाया जाता है।

स्केल-आउट, प्रतिकृति

MySQL RDS नए दासों को जोड़कर स्केल-आउट की अनुमति देता है। जब एक गुलाम बनाया जाता है, तो मास्टर का एक स्नैपशॉट लिया जाता है और इसका उपयोग एक नया होस्ट बनाने के लिए किया जाता है। यह हिस्सा काफी अच्छा काम करता है। दुर्भाग्य से, आप कोई और अधिक जटिल प्रतिकृति टोपोलॉजी नहीं बना सकते हैं जैसे कि मध्यवर्ती मास्टर्स को शामिल करना। आप एक मास्टर-मास्टर सेटअप बनाने में सक्षम नहीं हैं, जो किसी भी HA को Amazon (और मल्टी-एजेड परिनियोजन) के हाथों में छोड़ देता है। हम जो बता सकते हैं, उससे GTID को सक्षम करने का कोई तरीका नहीं है (ऐसा नहीं है कि आप इससे लाभान्वित हो सकते हैं क्योंकि आपके पास प्रतिकृति पर कोई नियंत्रण नहीं है, RDS में कोई चेंज मास्टर नहीं है), केवल नियमित, पुराने जमाने के बिनलॉग पोजीशन हैं।

GTID का अभाव मल्टीथ्रेडेड प्रतिकृति का उपयोग करना संभव नहीं बनाता है - जबकि RDS पैरामीटर समूहों का उपयोग करके कई श्रमिकों को सेट करना संभव है, GTID के बिना यह अनुपयोगी है। मुख्य मुद्दा यह है कि दुर्घटना के मामले में एकल बाइनरी लॉग स्थिति का पता लगाने का कोई तरीका नहीं है - कुछ कार्यकर्ता पीछे हो सकते थे, कुछ अधिक उन्नत हो सकते थे। यदि आप नवीनतम लागू किए गए ईवेंट का उपयोग करते हैं, तो आप उस डेटा को खो देंगे जो उन "पिछड़े" कर्मचारियों द्वारा अभी तक लागू नहीं किया गया है। यदि आप सबसे पुराने ईवेंट का उपयोग करेंगे, तो आपको "डुप्लिकेट कुंजी" त्रुटियों के साथ समाप्त होने की संभावना है, जो उन श्रमिकों द्वारा लागू की गई घटनाओं के कारण होती हैं जो अधिक उन्नत हैं। बेशक, इस समस्या को हल करने का एक तरीका है लेकिन यह मामूली नहीं है और इसमें समय लगता है - निश्चित रूप से ऐसा कुछ नहीं जिसे आप आसानी से स्वचालित कर सकें।

MySQL RDS पर बनाए गए उपयोगकर्ताओं के पास सुपर विशेषाधिकार नहीं है, इसलिए ऑपरेशन, जो स्टैंड-अलोन MySQL में सरल हैं, RDS में तुच्छ नहीं हैं। अमेज़ॅन ने उन कार्यों में से कुछ को करने के लिए उपयोगकर्ता को सशक्त बनाने के लिए संग्रहीत प्रक्रियाओं का उपयोग करने का निर्णय लिया। हम जो बता सकते हैं, उसमें कई संभावित मुद्दों को शामिल किया गया है, हालांकि यह हमेशा ऐसा नहीं रहा है - हमें याद है कि जब आप मास्टर पर अगले बाइनरी लॉग में नहीं घूम सकते थे। एक मास्टर क्रैश + बिनलॉग भ्रष्टाचार सभी दासों को तोड़ सकता है - अब उसके लिए एक प्रक्रिया है:rds_next_master_log ।

एक गुलाम को मैन्युअल रूप से एक मास्टर के रूप में पदोन्नत किया जा सकता है। यह आपको बहु-एजेड तंत्र (या इसे छोड़कर) के शीर्ष पर किसी प्रकार का एचए बनाने की अनुमति देगा, लेकिन यह इस तथ्य से व्यर्थ बना दिया गया है कि आप किसी भी मौजूदा दास को नए स्वामी को गुलाम नहीं बना सकते हैं। याद रखें, प्रतिकृति पर आपका कोई नियंत्रण नहीं है। यह पूरी कवायद को व्यर्थ बना देता है - जब तक कि आपका मास्टर आपके सभी ट्रैफ़िक को समायोजित नहीं कर सकता। एक नए स्वामी को बढ़ावा देने के बाद, आप इसे विफल करने में सक्षम नहीं हैं क्योंकि आपके पास आपके भार को संभालने के लिए कोई दास नहीं है। नए दासों को स्पिन करने में समय लगेगा क्योंकि ईबीएस स्नैपशॉट को पहले बनाना होगा और इसमें घंटों लग सकते हैं। फिर, इससे पहले कि आप उस पर भार डाल सकें, आपको बुनियादी ढांचे को गर्म करना होगा।

सुपर विशेषाधिकार का अभाव

जैसा कि हमने पहले कहा, आरडीएस उपयोगकर्ताओं को सुपर विशेषाधिकार प्रदान नहीं करता है और यह किसी ऐसे व्यक्ति के लिए परेशान हो जाता है जो इसे MySQL पर रखने के लिए उपयोग किया जाता है। यह मान लें कि, पहले हफ्तों में, आप सीखेंगे कि उन चीजों को करने के लिए कितनी बार आवश्यकता होती है जो आप अक्सर करते हैं - जैसे कि प्रश्नों को मारना या प्रदर्शन स्कीमा को संचालित करना। आरडीएस में, आपको संग्रहित प्रक्रियाओं की पूर्वनिर्धारित सूची से चिपके रहना होगा और सीधे चीजों को करने के बजाय उनका उपयोग करना होगा। आप निम्न क्वेरी का उपयोग करके उन सभी को सूचीबद्ध कर सकते हैं:

SELECT specific_name FROM information_schema.routines;

प्रतिकृति के साथ, कई कार्यों को कवर किया जाता है, लेकिन यदि आप ऐसी स्थिति में समाप्त हो गए हैं जो अभी तक कवर नहीं किया गया है, तो आप भाग्य से बाहर हैं।

इंटरऑपरेबिलिटी और हाइब्रिड क्लाउड सेटअप

यह एक अन्य क्षेत्र है जहां आरडीएस में लचीलेपन की कमी है। मान लें कि आप एक मिश्रित क्लाउड/ऑन-प्रिमाइसेस सेटअप बनाना चाहते हैं - आपके पास एक RDS अवसंरचना है और आप परिसर में कुछ दास बनाना चाहते हैं। आपको जिस मुख्य समस्या का सामना करना पड़ रहा है वह यह है कि तार्किक डंप लेने के अलावा डेटा को आरडीएस से बाहर ले जाने का कोई तरीका नहीं है। आप RDS डेटा का स्नैपशॉट ले सकते हैं लेकिन आपके पास उन तक पहुंच नहीं है और आप उन्हें AWS से दूर नहीं ले जा सकते। आपके पास xtrabackup, rsync या यहां तक ​​कि cp का उपयोग करने के लिए इंस्टेंस तक भौतिक पहुंच भी नहीं है। आपके लिए एकमात्र विकल्प mysqldump, mydumper या इसी तरह के टूल का उपयोग करना है। यह जटिलता जोड़ता है (चरित्र सेट और संयोजन सेटिंग्स में समस्याएं पैदा करने की क्षमता होती है) और यह समय लेने वाली है (तार्किक बैकअप टूल का उपयोग करके डेटा को डंप और लोड करने में लंबा समय लगता है)।

आरडीएस और बाहरी उदाहरण के बीच प्रतिकृति स्थापित करना संभव है (दोनों तरीकों से, इसलिए आरडीएस में डेटा माइग्रेट करना भी संभव है), लेकिन यह बहुत समय लेने वाली प्रक्रिया हो सकती है।

दूसरी ओर, यदि आप RDS परिवेश में रहना चाहते हैं और अटलांटिक या पूर्व से लेकर पश्चिमी तट तक अपने बुनियादी ढांचे का विस्तार करना चाहते हैं, तो RDS आपको ऐसा करने की अनुमति देता है - जब आप एक नया दास बनाते हैं तो आप आसानी से एक क्षेत्र चुन सकते हैं।

दुर्भाग्य से, यदि आप अपने मास्टर को एक क्षेत्र से दूसरे क्षेत्र में ले जाना चाहते हैं, तो डाउनटाइम के बिना यह वस्तुतः संभव नहीं है - जब तक कि आपका एकल नोड आपके सभी ट्रैफ़िक को संभाल नहीं सकता।

सुरक्षा

जबकि MySQL RDS एक प्रबंधित सेवा है, अमेज़ॅन के इंजीनियरों द्वारा सुरक्षा से संबंधित हर पहलू का ध्यान नहीं रखा जाता है। अमेज़ॅन इसे "साझा उत्तरदायित्व मॉडल" कहता है। संक्षेप में, अमेज़ॅन नेटवर्क और स्टोरेज लेयर की सुरक्षा का ख्याल रखता है (ताकि डेटा सुरक्षित तरीके से स्थानांतरित हो), ऑपरेटिंग सिस्टम (पैच, सुरक्षा सुधार)। वहीं, दूसरी तरफ यूजर को बाकी सिक्यॉरिटी मॉडल का ख्याल रखना होता है। सुनिश्चित करें कि आरडीएस इंस्टेंस के लिए और वीपीसी के भीतर यातायात सीमित है, सुनिश्चित करें कि डेटाबेस स्तर प्रमाणीकरण सही किया गया है (कोई पासवर्ड-कम MySQL उपयोगकर्ता खाता नहीं), सत्यापित करें कि एपीआई सुरक्षा सुनिश्चित की गई है (एएमआई सही ढंग से और न्यूनतम आवश्यक विशेषाधिकारों के साथ सेट हैं)। उपयोगकर्ता को बाहरी नेटवर्क में आरडीएस और वीपीसी के जोखिम को कम करने के लिए फ़ायरवॉल सेटिंग्स (सुरक्षा समूह) का भी ध्यान रखना चाहिए। पहले स्थान पर एन्क्रिप्टेड आरडीएस इंस्टेंस बनाकर, बाकी एन्क्रिप्शन पर डेटा को लागू करने के लिए उपयोगकर्ता की ज़िम्मेदारी भी है - या तो एप्लिकेशन स्तर पर या डेटाबेस स्तर पर।

डेटाबेस स्तर एन्क्रिप्शन को केवल इंस्टेंस निर्माण पर सक्षम किया जा सकता है, आप मौजूदा, पहले से चल रहे डेटाबेस को एन्क्रिप्ट नहीं कर सकते।

RDS की सीमाएं

यदि आप RDS का उपयोग करने की योजना बना रहे हैं या यदि आप पहले से ही इसका उपयोग कर रहे हैं, तो आपको MySQL RDS के साथ आने वाली सीमाओं के बारे में पता होना चाहिए।

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

MySQL डेटा निर्देशिका और लॉग तक सीधी पहुंच की कमी के कारण कार्रवाई करना कठिन हो जाता है जिसमें उन्हें शामिल है। यह हर बार होता है कि एक डीबीए को बाइनरी लॉग या टेल एरर, स्लो क्वेरी या सामान्य लॉग को पार्स करने की आवश्यकता होती है। हालांकि आरडीएस पर उन लॉग को एक्सेस करना संभव है, यह MySQL होस्ट पर शेल में लॉग इन करके आपको जो कुछ भी करने की आवश्यकता है, उससे अधिक बोझिल है। उन्हें स्थानीय रूप से डाउनलोड करने में भी कुछ समय लगता है और आप जो कुछ भी करते हैं उसमें अतिरिक्त विलंबता जुड़ जाती है।

प्रतिकृति टोपोलॉजी पर नियंत्रण की कमी, केवल बहु-एजेड परिनियोजन में उच्च उपलब्धता। यह देखते हुए कि आपके पास प्रतिकृति पर नियंत्रण नहीं है, आप अपने डेटाबेस परत में किसी भी प्रकार की उच्च उपलब्धता तंत्र को लागू नहीं कर सकते हैं। इससे कोई फर्क नहीं पड़ता कि आपके पास कई दास हैं, आप उनमें से कुछ को मास्टर उम्मीदवारों के रूप में उपयोग नहीं कर सकते हैं क्योंकि भले ही आप एक दास को एक स्वामी को बढ़ावा देते हैं, शेष दासों को इस नए स्वामी से मुक्त करने का कोई तरीका नहीं है। यह उपयोगकर्ताओं को मल्टी-एजेड परिनियोजन का उपयोग करने और लागत बढ़ाने के लिए मजबूर करता है ("छाया" उदाहरण मुफ्त नहीं आता है, उपयोगकर्ता को इसके लिए भुगतान करना पड़ता है)।

नियोजित डाउनटाइम के माध्यम से कम उपलब्धता। आरडीएस इंस्टेंस को तैनात करते समय, आपको 30 मिनट की साप्ताहिक समय खिड़की चुनने के लिए मजबूर किया जाता है, जिसके दौरान आपके आरडीएस इंस्टेंस पर रखरखाव संचालन निष्पादित किया जा सकता है। एक ओर, यह समझ में आता है क्योंकि RDS एक सेवा के रूप में एक डेटाबेस है, इसलिए आपके RDS उदाहरणों के हार्डवेयर और सॉफ़्टवेयर अपग्रेड AWS इंजीनियरों द्वारा प्रबंधित किए जाते हैं। दूसरी ओर, यह आपकी उपलब्धता को कम करता है क्योंकि आप अपने मास्टर डेटाबेस को रखरखाव अवधि की अवधि के लिए नीचे जाने से नहीं रोक सकते। फिर से, इस मामले में मल्टी-एजेड सेटअप का उपयोग करने से उपलब्धता बढ़ जाती है क्योंकि बदलाव पहले शैडो इंस्टेंस पर होते हैं और फिर फेलओवर निष्पादित किया जाता है। हालाँकि, विफलता स्वयं पारदर्शी नहीं है, इसलिए किसी न किसी तरह से, आप अपटाइम खो देते हैं। यह आपको अप्रत्याशित MySQL मास्टर विफलताओं को ध्यान में रखते हुए अपने ऐप को डिज़ाइन करने के लिए मजबूर करता है। ऐसा नहीं है कि यह एक खराब डिज़ाइन पैटर्न है - डेटाबेस किसी भी समय क्रैश हो सकते हैं और आपका एप्लिकेशन इस तरह से बनाया जाना चाहिए कि यह सबसे गंभीर परिदृश्य का भी सामना कर सके। यह सिर्फ इतना है कि आरडीएस के साथ, आपके पास उच्च उपलब्धता के लिए सीमित विकल्प हैं।

उच्च उपलब्धता कार्यान्वयन के लिए कम विकल्प। प्रतिकृति टोपोलॉजी प्रबंधन में लचीलेपन की कमी को देखते हुए, एकमात्र व्यवहार्य उच्च उपलब्धता विधि बहु-एजेड परिनियोजन है। यह विधि अच्छी है लेकिन MySQL प्रतिकृति के लिए उपकरण हैं जो डाउनटाइम को और भी कम कर देंगे। उदाहरण के लिए, MHA या ClusterControl जब ProxySQL के संबंध में उपयोग किया जाता है, तो एप्लिकेशन के लिए पारदर्शी विफलता प्रक्रिया (लंबे समय तक चलने वाले लेनदेन की कमी जैसी कुछ शर्तों के तहत) वितरित कर सकता है। आरडीएस पर रहते हुए, आप इस पद्धति का उपयोग नहीं कर पाएंगे।

आपके डेटाबेस के प्रदर्शन के बारे में कम जानकारी. जबकि आप MySQL से ही मेट्रिक्स प्राप्त कर सकते हैं, कभी-कभी यह स्थिति का पूर्ण 10k फीट दृश्य प्राप्त करने के लिए पर्याप्त नहीं होता है। कुछ बिंदु पर, अधिकांश उपयोगकर्ताओं को दोषपूर्ण हार्डवेयर या दोषपूर्ण बुनियादी ढांचे के कारण वास्तव में अजीब मुद्दों से निपटना होगा - खोए हुए नेटवर्क पैकेट, अचानक समाप्त किए गए कनेक्शन या अप्रत्याशित रूप से उच्च CPU उपयोग। जब आपके पास अपने MySQL होस्ट तक पहुंच होती है, तो आप बहुत से टूल्स का लाभ उठा सकते हैं जो आपको लिनक्स सर्वर की स्थिति का निदान करने में मदद करते हैं। आरडीएस का उपयोग करते समय, आप क्लाउडवॉच, अमेज़ॅन की निगरानी और ट्रेंडिंग टूल में कौन से मीट्रिक उपलब्ध हैं, तक सीमित हैं। किसी भी अधिक विस्तृत निदान के लिए सहायता से संपर्क करने और समस्या की जांच करने और उसे ठीक करने के लिए कहने की आवश्यकता होती है। यह जल्दी हो सकता है लेकिन यह एक बहुत लंबी प्रक्रिया भी हो सकती है जिसमें बहुत सारे आगे और पीछे के ईमेल संचार होते हैं।

MySQL RDS से डेटा प्राप्त करने की जटिल और समय लेने वाली प्रक्रिया के कारण विक्रेता लॉक-इन। RDS MySQL डेटा निर्देशिका तक पहुँच प्रदान नहीं करता है, इसलिए डेटा को बाइनरी तरीके से स्थानांतरित करने के लिए उद्योग मानक टूल जैसे xtrabackup का उपयोग करने का कोई तरीका नहीं है। दूसरी ओर, हुड के तहत आरडीएस अमेज़ॅन द्वारा बनाए रखा गया एक MySQL है, यह बताना मुश्किल है कि यह अपस्ट्रीम के साथ 100% संगत है या नहीं। RDS केवल AWS पर उपलब्ध है, इसलिए आप हाइब्रिड सेटअप नहीं कर पाएंगे।

सारांश

MySQL RDS में ताकत और कमजोरियां दोनों हैं। यह उन लोगों के लिए एक बहुत अच्छा टूल है जो डेटाबेस के संचालन की चिंता किए बिना एप्लिकेशन पर ध्यान केंद्रित करना चाहते हैं। आप एक डेटाबेस परिनियोजित करें और क्वेरी जारी करना प्रारंभ करें। बैकअप स्क्रिप्ट बनाने या निगरानी समाधान स्थापित करने की कोई आवश्यकता नहीं है क्योंकि यह पहले से ही AWS इंजीनियरों द्वारा किया जा चुका है - आपको केवल इसका उपयोग करने की आवश्यकता है।

MySQL RDS का एक स्याह पक्ष भी है। अधिक जटिल सेटअप बनाने और अधिक दास जोड़ने के बाहर स्केलिंग के विकल्पों की कमी। मल्टी-एजेड परिनियोजन के तहत प्रस्तावित की तुलना में बेहतर उच्च उपलब्धता के लिए समर्थन का अभाव। MySQL लॉग के लिए बोझिल पहुंच। MySQL डेटा निर्देशिका तक सीधी पहुंच का अभाव और भौतिक बैकअप के लिए समर्थन की कमी, जिससे डेटा को RDS इंस्टेंस से बाहर ले जाना मुश्किल हो जाता है।

संक्षेप में, आरडीएस आपके लिए ठीक काम कर सकता है यदि आप डेटाबेस के विस्तृत नियंत्रण पर उपयोग में आसानी को महत्व देते हैं। आपको यह ध्यान रखने की आवश्यकता है कि, भविष्य में किसी समय, आप MySQL RDS को पछाड़ सकते हैं। जरूरी नहीं कि हम यहां केवल प्रदर्शन के बारे में ही बात कर रहे हों। यह आपके संगठन की अधिक जटिल प्रतिकृति टोपोलॉजी की आवश्यकता या समय-समय पर उत्पन्न होने वाले विभिन्न मुद्दों से शीघ्रता से निपटने के लिए डेटाबेस संचालन में बेहतर अंतर्दृष्टि की आवश्यकता के बारे में है। उस स्थिति में, यदि आपका डेटासेट पहले से ही आकार में बड़ा हो गया है, तो आपको RDS से बाहर निकलना मुश्किल हो सकता है। आपके डेटा को RDS में स्थानांतरित करने का कोई भी निर्णय लेने से पहले, सूचना प्रबंधकों को विशिष्ट क्षेत्रों में अपने संगठन की आवश्यकताओं और बाधाओं पर विचार करना चाहिए।

अगले कुछ ब्लॉग पोस्ट में हम आपको दिखाएंगे कि आरडीएस से अपने डेटा को एक अलग स्थान पर कैसे ले जाया जाए। हम EC2 में प्रवास और ऑन-प्रिमाइसेस अवसंरचना दोनों पर चर्चा करेंगे।