MySQL या MariaDB के लिए HA समाधान तैयार करते समय अविश्वसनीय नेटवर्क से निपटना

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

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

MySQL या MariaDB HA के लिए दो मुख्य विकल्प

हमने इस विशेष विषय को एक श्वेत पत्र में काफी विस्तृत रूप से कवर किया है, लेकिन आइए MySQL और MariaDB के लिए उच्च उपलब्धता के निर्माण के दो मुख्य तरीकों को देखें।

गैलेरा क्लस्टर

गैलेरा क्लस्टर MySQL के लिए साझा-कुछ नहीं, वस्तुतः तुल्यकालिक क्लस्टर तकनीक है। यह बहु-लेखक सेटअप बनाने की अनुमति देता है जो दुनिया भर में फैल सकता है। गैलेरा कम-विलंबता वातावरण में पनपता है लेकिन इसे लंबे WAN कनेक्शन के साथ काम करने के लिए भी कॉन्फ़िगर किया जा सकता है। गैलेरा में एक अंतर्निहित कोरम तंत्र है जो यह सुनिश्चित करता है कि कुछ नोड्स के नेटवर्क विभाजन के मामले में डेटा से समझौता नहीं किया जाएगा।

MySQL प्रतिकृति

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

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

गैलेरा क्लस्टर - नेटवर्क समस्याएं

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

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

अस्थिर नेटवर्क के लिए गैलेरा क्लस्टर कैसे डिज़ाइन करें?

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

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

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

एक और समस्या फेलओवर है:यदि "मास्टर" गैलेरा नोड (वह जो अन्य डेटासेंटर में दासों के लिए मास्टर के रूप में कार्य करता है) विफल हो जाता है, तो दास को दूसरे, काम करने वाले मास्टर नोड को फिर से नियुक्त करने के लिए कुछ तंत्र बनाना होगा। यह किसी प्रकार की स्क्रिप्ट हो सकती है, वीआईपी के साथ कुछ कोशिश करना भी संभव है जहां "स्लेव" गैलेरा क्लस्टर वर्चुअल आईपी को बंद कर देता है जिसे हमेशा "मास्टर" क्लस्टर में जीवित गैलेरा नोड को सौंपा जाता है।

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

अस्थिर नेटवर्क के लिए MySQL प्रतिकृति कैसे डिज़ाइन करें?

पिछले खंड में, हमने गैलेरा क्लस्टर को कवर किया था और एक समाधान अतुल्यकालिक प्रतिकृति का उपयोग करना था। यह एक सादे अतुल्यकालिक प्रतिकृति सेटअप में कैसा दिखता है? आइए देखें कि कैसे एक अस्थिर नेटवर्क प्रतिकृति सेटअप में सबसे बड़ा व्यवधान पैदा कर सकता है।

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

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

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

सबसे पहले, कैसे बताएं कि कौन सा मेजबान मास्टर है और कौन सा नहीं है। दासों को स्वामी से अलग करने के लिए "read_only" चर का उपयोग करना सामान्य तरीकों में से एक है। यदि नोड ने read_only सक्षम किया है (read_only =1 सेट करें), यह एक दास है (क्योंकि दासों को किसी भी प्रत्यक्ष लेखन को संभालना नहीं चाहिए)। यदि नोड ने read_only अक्षम कर दिया है (सेट read_only=0), तो यह एक मास्टर है। चीजों को सुरक्षित बनाने के लिए, MySQL कॉन्फ़िगरेशन में read_only=1 सेट करने के लिए एक सामान्य तरीका है - पुनरारंभ होने के मामले में, यह सुरक्षित है यदि नोड दास के रूप में दिखाई देता है। ऐसी "भाषा" को प्रॉक्सीएसक्यूएल या मैक्सस्केल जैसे प्रॉक्सी द्वारा समझा जा सकता है।

आइए एक उदाहरण देखें।

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

यदि नोड 1 पुनरारंभ होता है, तो यह read_only =1 के साथ आएगा और इसे एक दास के रूप में पहचाना जाएगा। यह आदर्श नहीं है क्योंकि यह नकल नहीं कर रहा है लेकिन यह स्वीकार्य है। आदर्श रूप से, पुराने मास्टर को तब तक बिल्कुल भी नहीं दिखाना चाहिए जब तक कि इसे फिर से बनाया न जाए और नए मास्टर को बंद न कर दिया जाए।

यदि हमें नेटवर्क विभाजन से निपटना है तो अधिक समस्याग्रस्त स्थिति है। आइए एक ही सेटअप पर विचार करें:एप्लिकेशन टियर, प्रॉक्सी टियर और डेटाबेस।

जब नेटवर्क मास्टर को पहुंच से बाहर कर देता है, तो एप्लिकेशन प्रयोग करने योग्य नहीं होता है क्योंकि कोई भी लेखन इसे अपने गंतव्य तक नहीं पहुंचाता है। नए मास्टर को पदोन्नत किया जाता है, लेखन को उस पर पुनर्निर्देशित किया जाता है। फिर क्या होगा यदि नेटवर्क की समस्या समाप्त हो जाती है और पुराना मास्टर उपलब्ध हो जाता है? इसे रोका नहीं गया है, इसलिए यह अभी भी केवल read_only=0 का उपयोग कर रहा है:

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

इस समस्या से बचने के लिए क्या किया जा सकता है? कोई चांदी की गोली नहीं है, लेकिन मस्तिष्क के विभाजित होने की संभावना को कम करने के लिए कुछ उपाय किए जा सकते हैं।

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

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

आप क्लस्टर की स्थिति को संग्रहीत करने के लिए कॉन्सल या आदि जैसे टूल भी शामिल कर सकते हैं। प्रॉक्सी परत को कॉन्सल के डेटा का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है, न कि read_only चर की स्थिति के लिए। इसके बाद फ़ेलओवर प्रबंधन सॉफ़्टवेयर पर निर्भर करेगा कि वह कॉन्सल में आवश्यक परिवर्तन करें ताकि सभी प्रॉक्सी ट्रैफ़िक को एक सही, नए मास्टर को भेज सकें।

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

जैसा कि आप देख सकते हैं, कोई फर्क नहीं पड़ता कि हम गैलेरा या MySQL प्रतिकृति के बारे में बात कर रहे हैं, अस्थिर नेटवर्क एक गंभीर समस्या बन सकते हैं। दूसरी ओर, यदि आप पर्यावरण को सही ढंग से डिजाइन करते हैं, तब भी आप इसे काम कर सकते हैं। हमें उम्मीद है कि यह ब्लॉग पोस्ट आपको ऐसे वातावरण बनाने में मदद करेगी जो नेटवर्क न होने पर भी स्थिर रूप से काम करेगा।