AWS पर MySQL या MariaDB के प्रबंधन के लिए RDS बनाम EC2 की तुलना करना

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

Amazon RDS वर्तमान में विभिन्न MySQL और MariaDB संस्करणों के साथ-साथ MySQL-संगत Amazon Aurora DB इंजन का समर्थन करता है। यह प्रतिकृति का समर्थन करता है, लेकिन जैसा कि आप पूर्वनिर्धारित वेब कंसोल से उम्मीद कर सकते हैं, कुछ सीमाएं हैं।

RDS का उपयोग करते समय कुछ ट्रेडऑफ़ हैं। ये न केवल आपके डेटाबेस इंस्टेंस को प्रबंधित और प्रावधान करने के तरीके को प्रभावित कर सकते हैं, बल्कि प्रदर्शन, सुरक्षा और उच्च उपलब्धता जैसी महत्वपूर्ण चीजें भी प्रभावित कर सकते हैं।

इस ब्लॉग में, हम प्रतिकृति पर ध्यान देने के साथ RDS का उपयोग करने और EC2 पर MySQL चलाने के बीच के अंतरों पर एक नज़र डालेंगे। जैसा कि हम देखेंगे, EC2 इंस्टेंस पर MySQL को होस्ट करने या Amazon RDS का उपयोग करने के बीच निर्णय लेना कोई आसान काम नहीं है।

RDS प्लेटफ़ॉर्म ट्रेडऑफ़

डेटाबेस का सबसे बड़ा आकार जिसे AWS होस्ट कर सकता है, आपके स्रोत परिवेश, आपके स्रोत डेटाबेस में डेटा के आवंटन और आपका सिस्टम कितना व्यस्त है, इस पर निर्भर करता है।

AWS क्षेत्रों में विभाजित है। प्रत्येक AWS खाते की सीमा, प्रति क्षेत्र, AWS संसाधनों की संख्या पर होती है जिन्हें बनाया जा सकता है। एक बार जब किसी संसाधन की सीमा समाप्त हो जाती है, तो उस संसाधन को बनाने के लिए अतिरिक्त कॉल विफल हो जाएंगी।

Amazon RDS MySQL DB इंस्टेंस के लिए, InnoDB फ़ाइल-प्रति-टेबल टेबलस्पेस का उपयोग करते समय अधिकतम प्रावधानित संग्रहण सीमा तालिका के आकार को अधिकतम 6 TB तक सीमित कर देती है।

InnoDB फ़ाइल-प्रति-तालिका सुविधा कुछ ऐसी है जिस पर आपको विचार करना चाहिए, भले ही आप किसी बड़े डेटाबेस को क्लाउड में माइग्रेट नहीं करना चाहते हों। आप देख सकते हैं कि कुछ मौजूदा डीबी इंस्टेंस की सीमा कम है। उदाहरण के लिए, अप्रैल 2014 से पहले बनाए गए MySQL DB इंस्टेंस की फ़ाइल और तालिका आकार सीमा 2 TB है। यह 2-टीबी फ़ाइल आकार सीमा डीबी इंस्टेंस या अप्रैल 2014 से पहले लिए गए डीबी स्नैपशॉट से बनाई गई प्रतिकृति पढ़ें पर भी लागू होती है।

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

प्रतिकृति त्रुटि छोड़ें:

CALL mysql.rds_skip_repl_error;

प्रतिकृति रोकें:

CALL mysql.rds_stop_replication;

प्रतिकृति प्रारंभ करें

CALL mysql.rds_start_replication;

RDS इंस्टेंस को AWS के बाहर चल रहे MySQL इंस्टेंस की रीड रेप्लिका के रूप में कॉन्फ़िगर करता है।

CALL mysql.rds_set_external_master;

MySQL इंस्टेंस को AWS के बाहर चल रहे MySQL इंस्टेंस की रीड रेप्लिका नहीं रहने के लिए पुन:कॉन्फ़िगर करता है।

CALL mysql.rds_reset_external_master;

एक प्रमाणपत्र आयात करता है। एसएसएल संचार और एन्क्रिप्टेड प्रतिकृति को सक्षम करने के लिए इसकी आवश्यकता है।

CALL mysql.rds_import_binlog_ssl_material;

प्रमाणपत्र हटाता है।

CALL mysql.rds_remove_binlog_ssl_material;

मास्टर पर अगले बाइनरी लॉग की शुरुआत में प्रतिकृति मास्टर लॉग स्थिति को बदलता है।

CALL mysql.rds_next_master_log;

जबकि संग्रहीत कार्यविधियाँ कई कार्यों का ध्यान रखती हैं, यह सीखने की अवस्था का एक सा है। सुपर विशेषाधिकार का अभाव बाहरी प्रतिकृति निगरानी का उपयोग करने में भी समस्याएँ पैदा कर सकता है।

Amazon RDS वर्तमान में निम्नलिखित का समर्थन नहीं करता है:

• वैश्विक लेनदेन आईडी
• परिवहन योग्य टेबल स्पेस
• प्रमाणीकरण प्लगइन
• पासवर्ड शक्ति प्लगइन
• प्रतिकृति फ़िल्टर
• अर्ध-तुल्यकालिक प्रतिकृति

अंतिम लेकिन कम से कम - शेल तक पहुंच। अमेज़ॅन आरडीएस टेलनेट, सिक्योर शेल (एसएसएच), या विंडोज रिमोट डेस्कटॉप कनेक्शन (आरडीपी) के माध्यम से डीबी इंस्टेंस तक सीधे होस्ट एक्सेस की अनुमति नहीं देता है। आप अभी भी mysql क्लाइंट जैसे मानक टूल के माध्यम से DB से कनेक्ट करने के लिए किसी एप्लिकेशन होस्ट पर क्लाइंट का उपयोग कर सकते हैं।

अन्य सीमाएँ हैं, जैसा कि RDS दस्तावेज़ीकरण में वर्णित है।

EC2 पर MySQL के साथ उच्च उपलब्धता

परिनियोजन और प्रबंधन/रखरखाव कार्यों को स्वचालित करने के लिए (नियंत्रण बनाए रखते हुए), ClusterControl का उपयोग करना संभव है। RDS की तरह ही, आपके पास GUI के माध्यम से कुछ ही मिनटों में डेटाबेस सेटअप को परिनियोजित करने की सुविधा है। नोड्स जोड़ना, बैकअप शेड्यूल करना, फ़ेलओवर करना, और इसी तरह, GUI के माध्यम से भी आसानी से किया जा सकता है। MySQL को सीधे EC2 पर संचालित करने के विकल्प हैं, और इस तरह किसी के उच्च उपलब्धता विकल्पों पर नियंत्रण बनाए रखते हैं। इस मार्ग से नीचे जाते समय, यह समझना महत्वपूर्ण है कि आपके निपटान में विभिन्न AWS सुविधाओं का लाभ कैसे उठाया जाए। सुनिश्चित करें कि आप हमारा 'DIY क्लाउड डेटाबेस' श्वेत पत्र देखें।

तैनाती

ClusterControl विभिन्न उच्च उपलब्धता डेटाबेस सेटअप की तैनाती को स्वचालित कर सकता है - मास्टर-स्लेव प्रतिकृति से लेकर मल्टी-मास्टर क्लस्टर तक। सभी मुख्य MySQL फ्लेवर समर्थित हैं - Oracle MySQL, MariaDB और Percona Server। वीपीसी/सुरक्षा समूह के कुछ प्रारंभिक सेटअप की आवश्यकता है, और इन्हें DIY क्लाउड डेटाबेस श्वेतपत्र में अच्छी तरह से वर्णित किया गया है। ध्यान दें कि समान अवधारणाएं लागू होती हैं, चाहे वह AWS हो या Google क्लाउड या Azure

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

गैलेरा क्लस्टर के भीतर सिंक्रोनस प्रतिकृति और क्लस्टर और एक या अधिक दासों के बीच अतुल्यकालिक प्रतिकृति के संयोजन से 'हाइब्रिड प्रतिकृति' स्थापित करना संभव है। दास को विलंबित करने जैसे विकल्प डेटा को अतिरिक्त स्तर की सुरक्षा प्रदान करते हैं।

प्रॉक्सी परत

उच्च उपलब्धता प्राप्त करने के लिए, अत्यधिक उपलब्ध सेटअप को परिनियोजित करना पर्याप्त नहीं है। अनुप्रयोगों को किसी तरह यह जानना होगा कि कौन से नोड काम कर रहे हैं और कौन से नहीं। टोपोलॉजी में परिवर्तन, उदा। एक मास्टर को दूसरे होस्ट में ले जाना, किसी भी तरह से प्रचारित करने की आवश्यकता है ताकि एप्लिकेशन परत में त्रुटियों से बचा जा सके। ClusterControl HAProxy, MaxScale, और ProxySQL जैसे प्रॉक्सी की तैनाती का समर्थन करता है। HAProxy और ProxySQL के लिए, Keepalived और VirtualIP के साथ निरर्थक उदाहरणों को परिनियोजित करने के लिए अतिरिक्त विकल्प हैं।

क्रॉस-रीजन प्रतिकृति

Amazon RDS रीड रेप्लिका सेवाएं प्रदान करता है। क्रॉस-रीजन रेप्लिकाएं आपको रीडिंग को स्केल करने की क्षमता देती हैं, क्योंकि AWS की दुनिया भर के कई डेटासेंटर में अपनी सेवाएं हैं। सभी पढ़ी गई प्रतिकृतियां पहुंच योग्य हैं और अधिकतम पांच क्षेत्रों में पढ़ने के लिए उपयोग की जा सकती हैं। ये नोड स्वतंत्र हैं और आपके अपग्रेड पथ में उपयोग किए जा सकते हैं, या स्टैंडअलोन डेटाबेस में प्रचारित किए जा सकते हैं।

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

प्रतिकृति पढ़ने के विपरीत, डेटाबेस इंजन संस्करण उन्नयन प्राथमिक पर होता है। एक और अंतर यह है कि AWS RDS स्वचालित रूप से DRBD के साथ विफल हो जाएगा, जबकि रीड रेप्लिकेशंस (एसिंक्रोनस प्रतिकृति का उपयोग करके) को आपसे मैन्युअल संचालन की आवश्यकता होगी।

आरडीएस पर मल्टी-एजेड फेलओवर स्टैंडबाय इंस्टेंस को इंगित करने के लिए डीएनएस परिवर्तन का उपयोग करता है, अमेज़ॅन के अनुसार यह विफलता के दौरान 60-120 सेकंड के भीतर होना चाहिए। चूंकि स्टैंडबाय प्राथमिक के समान स्टोरेज डेटा का उपयोग करता है, इसलिए संभवतः लेनदेन/लॉग रिकवरी होगी। बड़े डेटाबेस InnoDB पुनर्प्राप्ति पर काफी समय व्यतीत कर सकते हैं, इसलिए कृपया अपनी DR योजना और RTO गणना में इस पर विचार करें।

बेशक, यह अतिरिक्त लागत के साथ जाता है। आइए कुछ बुनियादी उदाहरण देखें। 2vCPU, 4GB ram के साथ db.t2.medium होस्ट की लागत 185.98 USD प्रति माह है, जब आप Multizone (MZ) प्रतिकृति को 370.98 UDB पर सक्षम करते हैं तो कीमत दोगुनी हो जाएगी। कीमत क्षेत्र के अनुसार अलग-अलग होगी लेकिन यह MZ में दोगुनी हो जाएगी।

ईसी 2 के साथ इसे प्राप्त करने के लिए, आप अपनी वर्चुअल मशीनों को विभिन्न क्षेत्रों में तैनात कर सकते हैं। प्रत्येक एडब्ल्यूएस क्षेत्र पूरी तरह से स्वतंत्र है। AWS क्षेत्र की सेटिंग को EC2_REGION पर्यावरण चर सेट करके कंसोल में बदला जा सकता है, या इसे AWS कमांड लाइन इंटरफ़ेस के साथ --region पैरामीटर का उपयोग करके ओवरराइड किया जा सकता है। जब आपके सर्वर का सेट तैयार हो जाता है, तो आप अपनी प्रतिकृति को परिनियोजित करने और उसकी निगरानी करने के लिए ClusterControl का उपयोग कर सकते हैं। आप मानक आदेशों का उपयोग करके कंसोल के माध्यम से मैन्युअल रूप से प्रतिकृति भी सेट कर सकते हैं।

क्रॉस टेक्नोलॉजी प्रतिकृति

Amazon RDS MySQL या MariaDB DB इंस्टेंस और MySQL या MariaDB इंस्टेंस के बीच प्रतिकृति सेट करना संभव है जो Amazon RDS के बाहर है। यह बाइनरी लॉग के माध्यम से mysql में मानक प्रतिकृति विधि का उपयोग करके किया जाता है। बाइनरी लॉग को सक्षम करने के लिए, आपको my.cnf कॉन्फ़िगरेशन को संशोधित करने की आवश्यकता है। शेल तक पहुंच के बिना, आरडीएस में यह कार्य असंभव हो गया। यह इतने स्पष्ट तरीके से नहीं किया गया है। आपके पास दो विकल्प हैं। एक बैकअप को सक्षम करना है - अपने अमेज़ॅन आरडीएस डीबी इंस्टेंस पर स्वचालित बैकअप को 0 से अधिक के प्रतिधारण के साथ सेट करें। या प्रीबिल्ट स्लेव सर्वर पर प्रतिकृति सक्षम करें। दोनों कार्य बाइनरी लॉग को सक्षम करेंगे जिन्हें आप बाद में अपने प्रतिकृति के लिए उपयोग कर सकते हैं।

बिनलॉग को अपने मास्टर इंस्टेंस में तब तक बनाए रखें जब तक आप यह सत्यापित नहीं कर लेते कि उन्हें प्रतिकृति पर लागू किया गया है। यह रखरखाव सुनिश्चित करता है कि विफलता की स्थिति में आप अपने मास्टर इंस्टेंस को पुनर्स्थापित कर सकते हैं।

एक और रोडब्लॉक अनुमति हो सकती है। अमेज़ॅन आरडीएस डीबी इंस्टेंस पर प्रतिकृति शुरू करने के लिए आवश्यक अनुमतियां प्रतिबंधित हैं और आपके अमेज़ॅन आरडीएस मास्टर उपयोगकर्ता के लिए उपलब्ध नहीं हैं। इस वजह से, आपको अपने लाइव डेटाबेस और अपने Amazon RDS डेटाबेस के बीच प्रतिकृति सेट करने के लिए Amazon RDS mysql.rds_set_external_master और mysql.rds_start_replication कमांड का उपयोग करना चाहिए।

अमेज़ॅन आरडीएस इंस्टेंस के लिए विफलता घटनाओं की निगरानी करें जो आपकी प्रतिकृति है। यदि कोई विफलता होती है, तो डीबी इंस्टेंस जो आपकी प्रतिकृति है, एक नए होस्ट पर एक अलग नेटवर्क पते के साथ फिर से बनाया जा सकता है। फ़ेलओवर इवेंट की निगरानी कैसे करें, इस बारे में जानकारी के लिए, Amazon RDS इवेंट नोटिफिकेशन का उपयोग करना देखें।

नीचे दिए गए उदाहरण में, हम देखेंगे कि कैसे RDS से EC2 इंस्टेंस पर स्थित बाहरी DB में प्रतिकृति को सक्षम किया जाए।
आपके पास बाइनरी लॉग सक्षम होना चाहिए, हम यहां RDS स्लेव का उपयोग करते हैं।

बाइनरी लॉग को बनाए रखने के लिए घंटों की संख्या निर्दिष्ट करें।

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

आरडीएस मास्टर पर, निम्नलिखित कमांड के साथ प्रतिकृति उपयोगकर्ता बनाएं:

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

RDS SLAVE पर, कमांड चलाएँ:

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

RDS SLAVE पर, mysqldump को निम्न प्रारूप के साथ चलाएँ:

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

DB डंप को बाहरी डेटाबेस में आयात करें:

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

केवल RDS पर AWS द्वारा बनाई गई तालिकाओं को अनदेखा करने के लिए एक प्रतिकृति फ़िल्टर बनाएं

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

प्रतिकृति प्रारंभ करें

START SLAVE;

प्रतिकृति स्थिति सत्यापित करें

SHOW SLAVE STATUS;

अभी के लिए बस इतना ही। AWS पर MySQL को मैनेज करना एक बड़ा विषय है। अपने विचार हमें नीचे कमेंट सेक्शन में बताएं।