मारियाडीबी क्लस्टर में नया क्या है 10.4

पिछले ब्लॉगों में से एक में, हमने नई सुविधाओं को कवर किया था जो मारियाडीबी 10.4.1 में सामने आ रही हैं। हमने वहां उल्लेख किया है कि इस संस्करण में शामिल एक नया गैलेरा क्लस्टर रिलीज होगा। इस ब्लॉग पोस्ट में हम गैलेरा क्लस्टर 26.4.0 (या गैलेरा 4) की विशेषताओं के बारे में जानेंगे, उन पर एक त्वरित नज़र डालेंगे, और यह पता लगाएंगे कि मारियाडीबी गैलेरा क्लस्टर के साथ काम करते समय वे आपके सेटअप को कैसे प्रभावित करेंगे।

स्ट्रीमिंग प्रतिकृति

गैलेरा क्लस्टर किसी भी तरह से स्टैंडअलोन MySQL के लिए ड्रॉप-इन प्रतिस्थापन नहीं है। जिस तरह से राइटसेट सर्टिफिकेशन काम करता है, उसने कई सीमाएँ और किनारे के मामले पेश किए जो गंभीर रूप से गैलेरा क्लस्टर में माइग्रेट करने की क्षमता को सीमित कर सकते हैं। तीन सबसे आम सीमाएं हैं...

1. लंबे लेन-देन में समस्याएं
2. बड़े लेन-देन में समस्याएं
3. टेबल में हॉटस्पॉट की समस्या

यह देखना बहुत अच्छा है कि गैलेरा 4 स्ट्रीमिंग प्रतिकृति पेश करता है, जो इन सीमाओं को कम करने में मदद कर सकता है। आइए वर्तमान स्थिति की थोड़ा और विस्तार से समीक्षा करें।

लंबे समय तक चलने वाले लेन-देन

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

हॉटस्पॉट

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

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

फिर भी, एक नोड पर ट्रैफ़िक भेजना तीसरी समस्या को संभालने के लिए पर्याप्त नहीं है।

बड़े लेन-देन

यह ध्यान रखना महत्वपूर्ण है कि लेन-देन पूरा होने पर ही राइटसेट प्रमाणीकरण के लिए भेजा जाता है। फिर, सभी नोड्स को राइटसेट भेजा जाता है और प्रमाणन प्रक्रिया होती है। यह इस बात की सीमा को प्रेरित करता है कि एकल लेनदेन कितना बड़ा हो सकता है क्योंकि गैलेरा, राइटसेट तैयार करते समय, इसे इन-मेमोरी बफर में संग्रहीत करता है। बहुत बड़े लेन-देन से क्लस्टर का प्रदर्शन कम हो जाएगा। इसलिए दो चर पेश किए गए हैं:wsrep_max_ws_rows, जो प्रति लेनदेन पंक्तियों की संख्या को सीमित करता है (हालांकि इसे 0 - असीमित पर सेट किया जा सकता है) और, अधिक महत्वपूर्ण:wsrep_max_ws_size, जिसे 2 जीबी तक सेट किया जा सकता है। तो, आप गैलेरा क्लस्टर के साथ जो सबसे बड़ा लेन-देन कर सकते हैं, उसका आकार 2GB तक है। साथ ही, आपको यह भी ध्यान रखना होगा कि बड़े लेनदेन के प्रमाणीकरण और आवेदन में भी समय लगता है, "लैग" बनाने के बाद - लिखने के बाद पढ़ें, उस हिट नोड के अलावा जहां आपने शुरू में लेनदेन किया था, सबसे अधिक संभावना गलत डेटा के रूप में होगी लेन-देन अभी भी लागू किया जा रहा है।

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

हॉटस्पॉट के मामले में, स्ट्रीमिंग प्रतिकृति के साथ पंक्ति को अपडेट करते समय सभी नोड्स पर ताले प्राप्त करना संभव है। अन्य प्रश्न जो उसी पंक्ति को अपडेट करना चाहते हैं, उन्हें अपने परिवर्तनों को निष्पादित करने से पहले लॉक के जारी होने की प्रतीक्षा करनी होगी।

स्ट्रीमिंग प्रतिकृति से बड़े लेन-देन को लाभ होगा क्योंकि अब पूरे लेन-देन के समाप्त होने की प्रतीक्षा करने की आवश्यकता नहीं होगी और न ही वे लेन-देन के आकार तक सीमित होंगे - बड़े लेनदेन को टुकड़ों में विभाजित किया जाएगा। यह नेटवर्क का बेहतर उपयोग करने में भी मदद करता है - एक बार में 2GB डेटा भेजने के बजाय उसी 2GB डेटा को टुकड़ों में विभाजित किया जा सकता है और लंबी अवधि में भेजा जा सकता है।

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

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

बैकअप लॉक

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

कारण आवेदन से पढ़ता है

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

MariaDB Galera 10.4 में अपग्रेड करना

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

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