कई भौगोलिक स्थानों में वितरित डेटाबेस को देखना काफी सामान्य है। इस प्रकार के सेटअप को करने का एक परिदृश्य डिजास्टर रिकवरी के लिए है, जहां आपका स्टैंडबाय डेटा सेंटर आपके मुख्य डेटासेंटर से अलग स्थान पर स्थित है। यह भी आवश्यक हो सकता है ताकि डेटाबेस उपयोगकर्ताओं के करीब स्थित हो।
इस सेटअप को प्राप्त करने की मुख्य चुनौती डेटाबेस को इस तरह से डिजाइन करना है जिससे नेटवर्क विभाजन से संबंधित मुद्दों की संभावना कम हो। समाधानों में से एक नियमित अतुल्यकालिक (या अर्ध-तुल्यकालिक) प्रतिकृति के बजाय गैलेरा क्लस्टर का उपयोग करना हो सकता है। इस ब्लॉग में हम इस दृष्टिकोण के पेशेवरों और विपक्षों पर चर्चा करेंगे। यह दो ब्लॉगों की श्रृंखला का पहला भाग है। दूसरे भाग में हम जियो-डिस्ट्रिब्यूटेड गैलेरा क्लस्टर डिजाइन करेंगे और देखेंगे कि कैसे क्लस्टर कंट्रोल हमें ऐसे वातावरण को तैनात करने में मदद कर सकता है।
भू-वितरित समूहों के लिए एसिंक्रोनस प्रतिकृति के बजाय गैलेरा क्लस्टर क्यों?
आइए गैलेरा और नियमित प्रतिकृति के बीच मुख्य अंतरों पर विचार करें। नियमित प्रतिकृति आपको लिखने के लिए केवल एक नोड प्रदान करती है, इसका मतलब है कि दूरस्थ डेटासेंटर से प्रत्येक लेखन को मास्टर तक पहुंचने के लिए वाइड एरिया नेटवर्क (डब्ल्यूएएन) पर भेजा जाना होगा। इसका अर्थ यह भी है कि दूरस्थ डेटासेंटर में स्थित सभी प्रॉक्सी को संपूर्ण टोपोलॉजी की निगरानी करने में सक्षम होना होगा, जिसमें शामिल सभी डेटा केंद्रों में फैले हुए हैं क्योंकि उन्हें यह बताने में सक्षम होना चाहिए कि वर्तमान में कौन सा नोड मास्टर है।
इससे कई समस्याएं होती हैं। सबसे पहले, WAN में कई कनेक्शन स्थापित करने होंगे, यह विलंबता जोड़ता है और प्रॉक्सी के चलने वाले किसी भी चेक को धीमा कर देता है। इसके अलावा, यह प्रॉक्सी और डेटाबेस पर अनावश्यक ओवरहेड जोड़ता है। अधिकांश समय आप केवल स्थानीय डेटाबेस नोड्स में ट्रैफ़िक को रूट करने में रुचि रखते हैं। एकमात्र अपवाद मास्टर है और केवल इस वजह से प्रॉक्सी को स्थानीय डेटासेंटर में स्थित हिस्से के बजाय पूरे बुनियादी ढांचे को देखने के लिए मजबूर होना पड़ता है। बेशक, आप केवल चयन को रूट करने के लिए प्रॉक्सी का उपयोग करके इसे दूर करने का प्रयास कर सकते हैं, जबकि किसी अन्य विधि (डीएनएस द्वारा प्रबंधित मास्टर के लिए समर्पित होस्टनाम) का उपयोग करके मास्टर को एप्लिकेशन को इंगित करने के लिए, लेकिन यह जटिलता और चलती भागों के अनावश्यक स्तर जोड़ता है, जो डेटा संगतता खोए बिना एकाधिक नोड और नेटवर्क विफलताओं को संभालने की आपकी क्षमता को गंभीरता से प्रभावित कर सकता है।
गैलेरा क्लस्टर एकाधिक लेखकों का समर्थन कर सकता है। विलंबता भी एक कारक है, क्योंकि गैलेरा क्लस्टर में सभी नोड्स को राइटसेट प्रमाणित करने के लिए समन्वय और संचार करना होता है, यह भी कारण हो सकता है कि आप गैलेरा का उपयोग न करने का निर्णय ले सकते हैं जब विलंबता बहुत अधिक हो। यह प्रतिकृति समूहों में भी एक मुद्दा है - प्रतिकृति समूहों में विलंबता केवल दूरस्थ डेटा केंद्रों से लिखने को प्रभावित करती है, जबकि डेटासेंटर से कनेक्शन जहां मास्टर स्थित है, कम विलंबता कमिट से लाभान्वित होगा।
MySQL प्रतिकृति में आपको सबसे खराब स्थिति को भी ध्यान में रखना होगा और यह सुनिश्चित करना होगा कि विलंबित लेखन के साथ आवेदन ठीक है। मास्टर हमेशा बदल सकता है और आप यह सुनिश्चित नहीं कर सकते कि आप हर समय एक स्थानीय नोड को लिखेंगे।
प्रतिकृति और गैलेरा क्लस्टर के बीच एक और अंतर प्रतिकृति अंतराल का प्रबंधन है। भू-वितरित क्लस्टर अंतराल से गंभीर रूप से प्रभावित हो सकते हैं:विलंबता, WAN कनेक्शन का सीमित थ्रूपुट, यह सब प्रतिकृति के साथ बनाए रखने के लिए एक प्रतिकृति क्लस्टर की क्षमता को प्रभावित करेगा। कृपया ध्यान रखें कि प्रतिकृति एक से सभी ट्रैफ़िक उत्पन्न करती है।
सभी दासों को संपूर्ण प्रतिकृति ट्रैफ़िक प्राप्त करना होता है - आपके पास जितना डेटा है WAN पर दूरस्थ दासों को भेजने के लिए आपके द्वारा जोड़े गए प्रत्येक दूरस्थ दास के साथ बढ़ता है। इसका परिणाम WAN लिंक संतृप्ति में आसानी से हो सकता है, खासकर यदि आप बहुत सारे संशोधन करते हैं और WAN लिंक का थ्रूपुट अच्छा नहीं है। जैसा कि आप ऊपर दिए गए आरेख में देख सकते हैं, तीन डेटा केंद्रों और उनमें से प्रत्येक में तीन नोड्स के साथ मास्टर को WAN कनेक्शन पर 6x प्रतिकृति ट्रैफ़िक भेजना होता है।
गैलेरा क्लस्टर के साथ चीजें थोड़ी अलग हैं। शुरुआत के लिए, गैलेरा नोड्स को सिंक में रखने के लिए प्रवाह नियंत्रण का उपयोग करता है। यदि नोड्स में से एक पिछड़ने लगता है, तो इसमें बाकी क्लस्टर को धीमा करने और इसे पकड़ने के लिए कहने की क्षमता होती है। निश्चित रूप से, यह पूरे क्लस्टर के प्रदर्शन को कम करता है, लेकिन यह तब भी बेहतर है जब आप वास्तव में चयन के लिए दासों का उपयोग नहीं कर सकते क्योंकि वे समय-समय पर पिछड़ जाते हैं - ऐसे मामलों में आपको जो परिणाम मिलेंगे वे पुराने और गलत हो सकते हैं। 
गैलेरा क्लस्टर की एक अन्य विशेषता, जिसका उपयोग करने पर इसके प्रदर्शन में उल्लेखनीय सुधार हो सकता है WAN, खंड हैं। डिफ़ॉल्ट रूप से गैलेरा सभी संचार के लिए उपयोग करता है और प्रत्येक राइटसेट नोड द्वारा क्लस्टर में अन्य सभी नोड्स को भेजा जाता है। सेगमेंट का उपयोग करके इस व्यवहार को बदला जा सकता है। सेगमेंट उपयोगकर्ताओं को गैलेरा क्लस्टर को कई भागों में विभाजित करने की अनुमति देता है। प्रत्येक खंड में कई नोड हो सकते हैं और यह उनमें से एक को रिले नोड के रूप में चुनता है। इस तरह के नोड अन्य खंडों से राइटसेट प्राप्त करते हैं और उन्हें गैलेरा नोड्स में स्थानीय रूप से खंड में पुनर्वितरित करते हैं। परिणामस्वरूप, जैसा कि आप ऊपर दिए गए चित्र में देख सकते हैं, WAN पर जाने वाले प्रतिकृति ट्रैफ़िक को तीन गुना कम करना संभव है - WAN पर प्रतिकृति स्ट्रीम के केवल दो "प्रतिकृति" भेजे जा रहे हैं:एक प्रति डेटासेंटर प्रति दास एक की तुलना में MySQL प्रतिकृति में।
गैलेरा क्लस्टर नेटवर्क विभाजन प्रबंधन
जहाँ गैलेरा क्लस्टर चमकता है वह नेटवर्क विभाजन की हैंडलिंग है। गैलेरा क्लस्टर क्लस्टर में नोड्स की स्थिति की लगातार निगरानी करता है। प्रत्येक नोड अपने साथियों के साथ जुड़ने और क्लस्टर की स्थिति का आदान-प्रदान करने का प्रयास करता है। यदि नोड्स का सबसेट पहुंच योग्य नहीं है, तो गैलेरा संचार को रिले करने का प्रयास करता है ताकि यदि उन नोड्स तक पहुंचने का कोई तरीका है, तो वे पहुंच जाएंगे।
उपरोक्त आरेख में एक उदाहरण देखा जा सकता है:DC 1 ने कनेक्टिविटी खो दी DC2 के साथ लेकिन DC2 और DC3 कनेक्ट हो सकते हैं। इस मामले में DC3 में एक नोड का उपयोग DC1 से DC2 तक डेटा रिले करने के लिए किया जाएगा ताकि यह सुनिश्चित हो सके कि इंट्रा-क्लस्टर संचार को बनाए रखा जा सकता है।
गैलेरा क्लस्टर क्लस्टर की स्थिति के आधार पर कार्रवाई करने में सक्षम है। यह कोरम लागू करता है - क्लस्टर को संचालित करने में सक्षम होने के लिए अधिकांश नोड्स को उपलब्ध होना चाहिए। यदि नोड क्लस्टर से डिस्कनेक्ट हो जाता है और किसी अन्य नोड तक नहीं पहुंच सकता है, तो यह काम करना बंद कर देगा।
जैसा कि ऊपर दिए गए चित्र में देखा जा सकता है, DC1 में नेटवर्क संचार का आंशिक नुकसान होता है और प्रभावित नोड को क्लस्टर से हटा दिया जाता है, यह सुनिश्चित करते हुए कि एप्लिकेशन पुराने डेटा तक नहीं पहुंच पाएगा।
यह बड़े पैमाने पर भी सच है। DC1 ने अपना सारा संचार काट दिया। परिणामस्वरूप, क्लस्टर से संपूर्ण डेटासेंटर हटा दिया गया है और इसका कोई भी नोड ट्रैफ़िक की सेवा नहीं करेगा। बाकी क्लस्टर ने बहुमत बनाए रखा (9 में से 6 नोड उपलब्ध हैं) और इसने DC 2 और DC3 के बीच कनेक्शन रखने के लिए खुद को फिर से कॉन्फ़िगर किया। ऊपर दिए गए आरेख में हमने माना है कि लेखन DC2 में नोड को हिट करता है, लेकिन कृपया ध्यान रखें कि गैलेरा कई लेखकों के साथ चलने में सक्षम है।
MySQL प्रतिकृति में किसी भी प्रकार की क्लस्टर जागरूकता नहीं है, जिससे नेटवर्क समस्याओं को संभालने में समस्या होती है। यह अन्य नोड्स के साथ कनेक्शन खोने पर खुद को बंद नहीं कर सकता है। नेटवर्क विभाजन के बाद पुराने मास्टर को दिखाई देने से रोकने का कोई आसान तरीका नहीं है।
केवल संभावनाएं प्रॉक्सी परत या उससे भी अधिक तक सीमित हैं। आपको एक प्रणाली तैयार करनी होगी, जो क्लस्टर की स्थिति को समझने और आवश्यक कार्रवाई करने का प्रयास करेगी। एक संभावित तरीका है कि ऑर्केस्ट्रेटर जैसे क्लस्टर-अवेयर टूल का उपयोग करें और फिर स्क्रिप्ट चलाएं जो ऑर्केस्ट्रेटर आरएएफटी क्लस्टर की स्थिति की जांच करें और इस स्थिति के आधार पर, डेटाबेस लेयर पर आवश्यक कार्रवाई करें। यह आदर्श से बहुत दूर है क्योंकि डेटाबेस की तुलना में उच्च स्तर पर की गई कोई भी कार्रवाई अतिरिक्त विलंबता जोड़ती है:यह संभव बनाता है इसलिए समस्या दिखाई देती है और सही कार्रवाई करने से पहले डेटा स्थिरता से समझौता किया जाता है। दूसरी ओर, गैलेरा डेटाबेस स्तर पर कार्रवाई करता है, जिससे सबसे तेज़ प्रतिक्रिया संभव हो जाती है।
