MySQL और MariaDB के लिए HA - गैलेरा क्लस्टर में मास्टर-मास्टर प्रतिकृति की तुलना करना

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

इस ब्लॉग पोस्ट में, हम मास्टर-मास्टर प्रतिकृति की तुलना गैलेरा क्लस्टर से करने जा रहे हैं।

प्रतिकृति अवधारणाएं

तुलना करने से पहले, आइए इन दो प्रतिकृति तंत्रों के पीछे की बुनियादी अवधारणाओं की व्याख्या करें।

आम तौर पर, MySQL डेटाबेस में कोई भी संशोधन बाइनरी प्रारूप में एक घटना उत्पन्न करता है। चुने गए प्रतिकृति विधि के आधार पर इस घटना को अन्य नोड्स में ले जाया जाता है - MySQL प्रतिकृति (मूल) या गैलेरा प्रतिकृति (wsrep API के साथ पैच)।

MySQL प्रतिकृति

निम्नलिखित आरेख MySQL प्रतिकृति का उपयोग करते समय एक नोड से दूसरे नोड में एक सफल लेनदेन के डेटा प्रवाह को दिखाता है:

बाइनरी इवेंट मास्टर के बाइनरी लॉग में लिखा जाता है। दास (ओं) के माध्यम से slave_IO_thread मास्टर के बाइनरी लॉग से बाइनरी घटनाओं को खींचेगा और उन्हें इसके रिले लॉग में दोहराएगा। दास_एसक्यूएल_थ्रेड फिर रिले लॉग से ईवेंट को अतुल्यकालिक रूप से लागू करेगा। प्रतिकृति की अतुल्यकालिक प्रकृति के कारण, जब मास्टर परिवर्तन करता है तो दास सर्वर के पास डेटा होने की गारंटी नहीं होती है।

आदर्श रूप से, MySQL प्रतिकृति में केवल-पढ़ने के लिए सर्वर के रूप में कॉन्फ़िगर करने के लिए दास को केवल read_only =ON या super_read_only =ON सेट करके कॉन्फ़िगर किया जाएगा। दास को आकस्मिक लेखन से बचाने के लिए यह एक एहतियात है जो मास्टर विफलता (जैसे, गलत लेनदेन) के दौरान डेटा असंगति या विफलता का कारण बन सकता है। हालांकि, मास्टर-मास्टर सक्रिय-सक्रिय प्रतिकृति सेटअप में, राइट-ओनली को अन्य मास्टर पर अक्षम किया जाना चाहिए ताकि राइट्स को एक साथ संसाधित किया जा सके। प्राथमिक मास्टर को सर्कुलर प्रतिकृति को सक्षम करने के लिए CHANGE MASTER कथन का उपयोग करके द्वितीयक मास्टर से दोहराने के लिए कॉन्फ़िगर किया जाना चाहिए।

गैलेरा प्रतिकृति

निम्नलिखित आरेख गैलेरा क्लस्टर के लिए एक नोड से दूसरे नोड में एक सफल लेनदेन के डेटा प्रतिकृति प्रवाह को दिखाता है:

घटना को एक राइटसेट में समझाया गया है और गैलेरा प्रतिकृति का उपयोग करके प्रवर्तक नोड से क्लस्टर में अन्य नोड्स में प्रसारित किया गया है। राइटसेट प्रत्येक गैलेरा नोड पर प्रमाणन से गुजरता है और यदि यह पास हो जाता है, तो एप्लायर थ्रेड्स राइटसेट को अतुल्यकालिक रूप से लागू करेंगे। इसका मतलब यह है कि वैश्विक कुल क्रम में सभी भाग लेने वाले नोड्स के समझौते के बाद, दास सर्वर अंततः सुसंगत हो जाएगा। यह तार्किक रूप से सिंक्रोनस है, लेकिन वास्तविक लेखन और टेबलस्पेस के लिए प्रतिबद्ध स्वतंत्र रूप से होता है, और इस प्रकार प्रत्येक नोड पर एसिंक्रोनस रूप से सभी नोड्स पर परिवर्तन के प्रचार की गारंटी के साथ होता है।

प्राथमिक कुंजी टकराव से बचना

मास्टर-मास्टर सेटअप में MySQL प्रतिकृति को तैनात करने के लिए, दो या दो से अधिक प्रतिकृति मास्टर्स के बीच INSERT के लिए प्राथमिक कुंजी टकराव से बचने के लिए ऑटो वृद्धि मूल्य को समायोजित करना होगा। यह मास्टर्स पर प्राथमिक कुंजी मान को एक-दूसरे को इंटरलीव करने की अनुमति देता है और एक ही ऑटो इंक्रीमेंट नंबर को किसी भी नोड पर दो बार इस्तेमाल होने से रोकता है। प्रतिकृति सेटअप में मास्टर्स की संख्या के आधार पर यह व्यवहार मैन्युअल रूप से कॉन्फ़िगर किया जाना चाहिए। auto_increment_increment . का मान नकल करने वाले मास्टर्स और auto_increment_offset . की संख्या के बराबर उनके बीच अद्वितीय होना चाहिए। उदाहरण के लिए, निम्न पंक्तियाँ संगत my.cnf के अंदर मौजूद होनी चाहिए:

मास्टर1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

मास्टर2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

इसी तरह, गैलेरा क्लस्टर ऑटो इंक्रीमेंट वैल्यू को नियंत्रित करके और wsrep_auto_increment_control के साथ स्वचालित रूप से ऑफसेट करके प्राथमिक कुंजी टकराव से बचने के लिए इसी ट्रिक का उपयोग करता है। चर। यदि 1 (डिफ़ॉल्ट) पर सेट किया जाता है, तो स्वचालित रूप से auto_increment_increment को समायोजित कर देगा और auto_increment_offset क्लस्टर के आकार के अनुसार चर, और जब क्लस्टर का आकार बदलता है। यह auto_increment के कारण प्रतिकृति विरोधों से बचा जाता है। मास्टर-दास वातावरण में, इस चर को बंद पर सेट किया जा सकता है।

इस कॉन्फ़िगरेशन का परिणाम यह है कि ऑटो इंक्रीमेंट मान अनुक्रमिक क्रम में नहीं होगा, जैसा कि तीन-नोड गैलेरा क्लस्टर की निम्न तालिका में दिखाया गया है:

यदि कोई एप्लिकेशन निम्न क्रम में निम्नलिखित नोड्स पर सम्मिलित कार्य करता है:

• Node1, Node3, Node2, Node3, Node3, Node1, Node3 ..

तब प्राथमिक कुंजी मान जो तालिका में संग्रहीत किया जाएगा वह होगा:

• 1, 6, 8, 9, 12, 13, 15 ..

सीधे शब्दों में कहें, मास्टर-मास्टर प्रतिकृति (MySQL प्रतिकृति या गैलेरा) का उपयोग करते समय, आपका एप्लिकेशन अपने डेटासेट में गैर-अनुक्रमिक ऑटो-इन्क्रीमेंट मानों को सहन करने में सक्षम होना चाहिए।

ClusterControl उपयोगकर्ताओं के लिए, ध्यान दें कि यह MySQL मास्टर-मास्टर प्रतिकृति की तैनाती का समर्थन करता है, प्रति प्रतिकृति क्लस्टर में दो मास्टर्स की सीमा के साथ, केवल सक्रिय-निष्क्रिय सेटअप के लिए। इसलिए, ClusterControl जानबूझकर मास्टर्स को auto_increment_increment के साथ कॉन्फ़िगर नहीं करता है और auto_increment_offset चर।

डेटा संगतता

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

दूसरी ओर गैलेरा क्लस्टर डेटा असंगति के लिए एक सुरक्षा उपाय के साथ आता है, जिससे किसी भी कारण से किसी भी राइटसेट को लागू करने में विफल रहने पर नोड क्लस्टर से बेदखल हो जाएगा। उदाहरण के लिए, जब एक गैलेरा नोड अंतर्निहित स्टोरेज इंजन (MySQL/MariaDB) द्वारा आंतरिक त्रुटि के कारण राइटसेट लागू करने में विफल रहता है, तो नोड निम्न त्रुटि के साथ क्लस्टर से खुद को बाहर निकाल लेगा:

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

डेटा स्थिरता को ठीक करने के लिए, क्लस्टर में शामिल होने की अनुमति देने से पहले आपत्तिजनक नोड को फिर से समन्वयित करना होगा। यह मैन्युअल रूप से किया जा सकता है या स्नैपशॉट स्थिति हस्तांतरण (एक दाता से पूर्ण समन्वयन) को ट्रिगर करने के लिए डेटा निर्देशिका को मिटाकर किया जा सकता है।

MySQL मास्टर-मास्टर प्रतिकृति डेटा स्थिरता सुरक्षा को लागू नहीं करता है और एक दास को विचलन करने की अनुमति है, उदाहरण के लिए, डेटा के एक सबसेट को दोहराना या पीछे रहना, जो दास को मास्टर के साथ असंगत बनाता है। यह डेटा को एक प्रवाह में दोहराने के लिए डिज़ाइन किया गया है - मास्टर से दास तक। डेटा संगतता जाँच मैन्युअल रूप से या Percona Toolkit pt-table-checksum या mysql-replication-check जैसे बाहरी उपकरणों के माध्यम से की जानी चाहिए।

संघर्ष समाधान

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

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

नोड की सहमति और विफलता

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

MySQL प्रतिकृति में, एक मास्टर अपने दास (दासों) की परवाह नहीं करता है, जबकि एक दास केवल अपने एकमात्र स्वामी के साथ slave_IO_thread के माध्यम से सहमति रखता है। मास्टर के बाइनरी लॉग से बाइनरी घटनाओं की नकल करते समय प्रक्रिया। यदि कोई मास्टर नीचे चला जाता है, तो यह प्रतिकृति को तोड़ देगा और लिंक को फिर से स्थापित करने का प्रयास प्रत्येक slave_net_timeout पर किया जाएगा। (60 सेकंड के लिए डिफ़ॉल्ट)। एप्लिकेशन या लोड बैलेंसर के दृष्टिकोण से, प्रतिकृति दास के लिए स्वास्थ्य जांच प्रक्रियाओं में कम से कम निम्नलिखित स्थिति की जाँच शामिल होनी चाहिए:

• सेकंड_बिहाइंड_मास्टर
• Slave_IO_Running
• Slave_SQL_Running
• केवल पढ़ने के लिए चर
• super_read_only चर (MySQL 5.7.8 और बाद के संस्करण)

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

नोड प्रोविजनिंग

प्रतिकृति शुरू होने से पहले नोड को क्लस्टर के साथ सिंक में लाने की प्रक्रिया को प्रोविजनिंग के रूप में जाना जाता है। MySQL प्रतिकृति में, एक नया नोड प्रावधान करना एक मैन्युअल प्रक्रिया है। प्रतिकृति लिंक स्थापित करने से पहले किसी को मास्टर का बैकअप लेना होगा और इसे नए नोड पर पुनर्स्थापित करना होगा। मौजूदा प्रतिकृति नोड के लिए, यदि मास्टर के बाइनरी लॉग को घुमाया गया है (expire_logs_days पर आधारित) , डिफ़ॉल्ट से 0 का अर्थ है कोई स्वचालित निष्कासन नहीं), आपको इस प्रक्रिया का उपयोग करके नोड को फिर से प्रावधान करना पड़ सकता है। इसमें आपकी मदद करने के लिए Percona Toolkit pt-table-sync और ClusterControl जैसे बाहरी टूल भी हैं। ClusterControl केवल दो क्लिक के साथ दास को फिर से समन्वयित करने का समर्थन करता है। आपके पास सक्रिय मास्टर या मौजूदा बैकअप से बैकअप लेकर फिर से सिंक करने के विकल्प हैं।

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

ढीला युग्मित बनाम कसकर युग्मित

MySQL प्रतिकृति धीमी कनेक्शन में भी बहुत अच्छी तरह से काम करती है, और ऐसे कनेक्शन के साथ जो निरंतर नहीं हैं। इसका उपयोग विभिन्न हार्डवेयर, पर्यावरण और ऑपरेटिंग सिस्टम में भी किया जा सकता है। MyISAM, Aria, MEMORY और ARCHIVE सहित अधिकांश स्टोरेज इंजन इसका समर्थन करते हैं। यह शिथिल युग्मित सेटअप, MySQL मास्टर-मास्टर प्रतिकृति को कम प्रतिबंध के साथ मिश्रित वातावरण में अच्छी तरह से काम करने की अनुमति देता है।

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

निष्कर्ष

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

उपरोक्त हमारे बिंदुओं को सरल बनाने के लिए, निम्नलिखित कारण उचित ठहराते हैं कि MySQL मास्टर-मास्टर प्रतिकृति का उपयोग कब किया जाए:

• ऐसी चीज़ें जो गैलेरा द्वारा समर्थित नहीं हैं:
  • गैर-InnoDB/XtraDB तालिकाओं जैसे MyISAM, Aria, MEMORY या ARCHIVE के लिए प्रतिकृति।
  • एक्सए लेनदेन।
  • मास्टर्स के बीच स्टेटमेंट-आधारित प्रतिकृति (जैसे, जब बैंडविड्थ बहुत महंगा हो)।
  • LOCK TABLES स्टेटमेंट जैसे स्पष्ट लॉकिंग पर निर्भर।
  • सामान्य क्वेरी लॉग और धीमी क्वेरी लॉग को फ़ाइल के बजाय एक तालिका पर निर्देशित किया जाना चाहिए।
• ढीला युग्मित सेटअप जहां हार्डवेयर विनिर्देश, सॉफ़्टवेयर संस्करण और कनेक्शन की गति प्रत्येक मास्टर पर महत्वपूर्ण रूप से भिन्न होती है।
• जब आपके पास पहले से ही एक MySQL प्रतिकृति श्रृंखला है और आप अतिरेक के लिए एक और सक्रिय/बैकअप मास्टर जोड़ना चाहते हैं ताकि यदि कोई मास्टर अनुपलब्ध हो तो विफलता और पुनर्प्राप्ति समय को तेज किया जा सके।
• यदि आपके एप्लिकेशन को गैलेरा क्लस्टर सीमाओं के आसपास काम करने के लिए संशोधित नहीं किया जा सकता है और ProxySQL या MaxScale जैसे MySQL-अवेयर लोड बैलेंसर का होना कोई विकल्प नहीं है।

MySQL मास्टर-मास्टर प्रतिकृति पर गैलेरा क्लस्टर को चुनने के कारण:

• एकाधिक मास्टर्स को सुरक्षित रूप से लिखने की क्षमता।
• डेटा संगतता स्वचालित रूप से सभी डेटाबेस में प्रबंधित (और गारंटीकृत) होती है।
• नए डेटाबेस नोड आसानी से पेश और समन्वयित होते हैं।
• विफलताओं या विसंगतियों का स्वतः पता चल जाता है।
• सामान्य तौर पर, अधिक उन्नत और मजबूत उच्च उपलब्धता सुविधाएं।