इस तीन-भाग वाली ब्लॉग श्रृंखला में, हमने भाग I में MySQL होस्टिंग के लिए एक उच्च उपलब्धता (HA) फ्रेमवर्क पेश किया, और भाग II में MySQL सेमीसिंक्रोनस प्रतिकृति के विवरण पर चर्चा की। अब भाग III में, हम समीक्षा करते हैं कि फ्रेमवर्क कुछ महत्वपूर्ण MySQL विफलता परिदृश्यों को कैसे संभालता है और उच्च उपलब्धता सुनिश्चित करने के लिए ठीक हो जाता है।
MySQL विफलता परिदृश्य
परिदृश्य 1 - मास्टर MySQL नीचे चला जाता है
- Corosync और Pacemaker Framework यह पता लगाता है कि मास्टर MySQL अब उपलब्ध नहीं है। पेसमेकर मास्टर संसाधन को अवनत कर देता है और यदि संभव हो तो MySQL सेवा के पुनरारंभ के साथ पुनर्प्राप्त करने का प्रयास करता है।
- इस बिंदु पर, प्रतिकृति की अर्धतुल्यकालिक प्रकृति के कारण, मास्टर पर किए गए सभी लेन-देन कम से कम एक दास द्वारा प्राप्त किए गए हैं।
- पेसमेकर तब तक इंतजार करता है जब तक कि सभी प्राप्त लेनदेन दासों पर लागू नहीं हो जाते और दासों को उनके प्रचार स्कोर की रिपोर्ट करने देता है। स्कोर की गणना इस तरह से की जाती है कि यदि कोई दास पूरी तरह से मास्टर के साथ तालमेल बिठाता है तो स्कोर '0' होता है, और अन्यथा एक ऋणात्मक संख्या होती है।
- पेसमेकर उस स्लेव को चुनता है जिसने 0 स्कोर की सूचना दी है और उस स्लेव को बढ़ावा देता है जो अब मास्टर MySQL की भूमिका ग्रहण करता है जिस पर लिखने की अनुमति है।
- स्लेव प्रमोशन के बाद, रिसोर्स एजेंट एक DNS रीरूटिंग मॉड्यूल को ट्रिगर करता है। मॉड्यूल नए मास्टर के आईपी पते के साथ प्रॉक्सी डीएनएस प्रविष्टि को अपडेट करता है, इस प्रकार, सभी एप्लिकेशन को नए मास्टर पर पुनर्निर्देशित करने की सुविधा देता है।
- पेसमेकर इस नए मास्टर से नकल करना शुरू करने के लिए उपलब्ध स्लेव को भी सेट करता है।
इस प्रकार, जब भी एक मास्टर MySQL नीचे चला जाता है (चाहे MySQL क्रैश, OS क्रैश, सिस्टम रिबूट, आदि के कारण), हमारा HA फ्रेमवर्क इसका पता लगाता है और एक उपयुक्त स्लेव को बढ़ावा देता है गुरु की भूमिका निभाएं। यह सुनिश्चित करता है कि सिस्टम अनुप्रयोगों के लिए उपलब्ध बना रहे।
#MySQL उच्च उपलब्धता फ्रेमवर्क समझाया गया - भाग III:विफलता परिदृश्य ट्वीट करने के लिए क्लिक करें
परिदृश्य 2 - स्लेव MySQL नीचे चला जाता है
- Corosync और Pacemaker Framework यह पता लगाता है कि स्लेव MySQL अब उपलब्ध नहीं है।
- पेसमेकर नोड पर MySQL को पुनरारंभ करने का प्रयास करके संसाधन को पुनर्प्राप्त करने का प्रयास करता है। यदि यह ऊपर आता है, तो इसे एक दास के रूप में वर्तमान मास्टर में वापस जोड़ दिया जाता है और प्रतिकृति जारी रहती है।
- यदि पुनर्प्राप्ति विफल हो जाती है, तो पेसमेकर उस संसाधन को डाउन के रूप में रिपोर्ट करता है - जिसके आधार पर अलर्ट या सूचनाएं उत्पन्न की जा सकती हैं। यदि आवश्यक हो, तो स्केलग्रिड सहायता टीम इस नोड की पुनर्प्राप्ति को संभालेगी।
- इस मामले में, MySQL सेवाओं की उपलब्धता पर कोई प्रभाव नहीं पड़ता है।
परिदृश्य 3 - नेटवर्क विभाजन - नेटवर्क कनेक्टिविटी मास्टर और स्लेव नोड्स के बीच टूट जाती है
यह किसी भी वितरित प्रणाली में एक शास्त्रीय समस्या है जहां प्रत्येक नोड को लगता है कि अन्य नोड्स नीचे हैं, जबकि वास्तव में, नोड्स के बीच केवल नेटवर्क संचार टूट गया है। इस परिदृश्य को आमतौर पर स्प्लिट-ब्रेन परिदृश्य के रूप में जाना जाता है, और यदि इसे ठीक से संभाला नहीं जाता है, तो यह एक से अधिक नोड को मास्टर MySQL होने का दावा कर सकता है जो बदले में डेटा विसंगतियों और भ्रष्टाचार की ओर जाता है।
आइए एक उदाहरण का उपयोग करके समीक्षा करें कि हमारा ढांचा क्लस्टर में विभाजित-मस्तिष्क परिदृश्यों से कैसे निपटता है। हम मानते हैं कि नेटवर्क समस्याओं के कारण, क्लस्टर दो समूहों में विभाजित हो गया है - एक समूह में मास्टर और दूसरे समूह में 2 दास, और हम इसे [(M), (S1,S2)] के रूप में निरूपित करेंगे।
- Corosync पता लगाता है कि मास्टर नोड स्लेव नोड्स के साथ संचार करने में सक्षम नहीं है, और स्लेव नोड एक दूसरे के साथ संचार कर सकते हैं, लेकिन मास्टर के साथ नहीं ।
- मास्टर नोड कोई भी लेनदेन करने में सक्षम नहीं होगा क्योंकि सेमीसिंक्रोनस प्रतिकृति मास्टर के प्रतिबद्ध होने से पहले कम से कम एक दास से पावती की अपेक्षा करता है। उसी समय, पेसमेकर सेटिंग 'नो-कोरम-पॉलिसी =स्टॉप' के आधार पर कोरम की कमी के कारण पेसमेकर मास्टर नोड पर MySQL को बंद कर देता है। यहां कोरम का अर्थ है अधिकांश नोड्स, या 3-नोड क्लस्टर सेटअप में तीन में से दो। चूंकि क्लस्टर के इस विभाजन में केवल एक मास्टर नोड चल रहा है, इसलिए नो-कोरम-नीति सेटिंग ट्रिगर हो जाती है जिससे MySQL मास्टर बंद हो जाता है।
- अब, विभाजन पर पेसमेकर [(S1), (S2)] पता लगाता है कि क्लस्टर में कोई मास्टर उपलब्ध नहीं है और एक प्रचार प्रक्रिया शुरू करता है। यह मानते हुए कि S1 मास्टर के साथ अद्यतित है (जैसा कि सेमीसिंक्रोनस प्रतिकृति द्वारा गारंटी दी गई है), फिर इसे नए मास्टर के रूप में प्रचारित किया जाता है।
- एप्लिकेशन ट्रैफ़िक को इस नए मास्टर MySQL नोड पर रीडायरेक्ट कर दिया जाएगा और स्लेव S2 नए मास्टर से प्रतिकृति बनाना शुरू कर देगा।
इस प्रकार, हम देखते हैं कि MySQL HA फ्रेमवर्क स्प्लिट-ब्रेन परिदृश्यों को प्रभावी ढंग से संभालता है, जिससे मास्टर और स्लेव नोड्स के बीच नेटवर्क कनेक्टिविटी टूटने की स्थिति में डेटा स्थिरता और उपलब्धता दोनों सुनिश्चित होती है।
पी>यह सेमीसिंक्रोनस प्रतिकृति और कोरोसिंक प्लस पेसमेकर स्टैक का उपयोग करके MySQL उच्च उपलब्धता (HA) ढांचे पर हमारी 3-भाग ब्लॉग श्रृंखला का समापन करता है। स्केलग्रिड में, हम AWS पर MySQL और Azure पर MySQL के लिए अत्यधिक उपलब्ध होस्टिंग की पेशकश करते हैं जो इस ब्लॉग श्रृंखला में बताई गई अवधारणाओं के आधार पर कार्यान्वित की जाती है। हमारे समाधानों के नि:शुल्क परीक्षण के लिए कृपया स्केलग्रिड कंसोल पर जाएं।
