कई अनुप्रयोगों के लिए स्वचालित विफलता बहुत अधिक होनी चाहिए - अपटाइम को मंजूरी के लिए लिया जाता है। यह स्वीकार करना काफी कठिन है कि कोई एप्लिकेशन 20 या 30 मिनट के लिए बंद है क्योंकि किसी को कार्रवाई करने से पहले लॉग इन करने और स्थिति की जांच करने के लिए पेज करना पड़ता है।
वास्तविक दुनिया में, प्रतिकृति सेटअप समय के साथ जटिल हो जाते हैं, कभी-कभी गड़बड़ हो जाते हैं। और अड़चनें हैं। उदाहरण के लिए, सेटअप में प्रत्येक नोड एक अच्छा मास्टर उम्मीदवार नहीं बनाता है। हो सकता है कि हार्डवेयर अलग हो और कुछ प्रतिकृतियों में कम शक्तिशाली हार्डवेयर हों क्योंकि वे कुछ विशिष्ट प्रकार के कार्यभार को संभालने के लिए समर्पित हैं? हो सकता है कि आप एक नए MySQL संस्करण में माइग्रेशन के बीच में हों और कुछ दास पहले ही अपग्रेड किए जा चुके हों? इसके बजाय आपके पास पुराने प्रतिकृतियों की नकल करने वाले अधिक हाल के संस्करण में एक मास्टर नहीं होगा, क्योंकि यह प्रतिकृति को तोड़ सकता है। यदि आपके पास दो डेटासेंटर हैं, एक सक्रिय है और एक डिजास्टर रिकवरी के लिए है, तो आप मास्टर उम्मीदवारों को केवल सक्रिय डेटासेंटर में चुनना पसंद कर सकते हैं, ताकि मास्टर को एप्लिकेशन होस्ट के करीब रखा जा सके। वे केवल उदाहरण की स्थितियाँ हैं, जहाँ आपको फ़ेलओवर प्रक्रिया के दौरान मैन्युअल हस्तक्षेप की आवश्यकता हो सकती है। सौभाग्य से, कई फ़ेलओवर टूल में श्वेतसूची और ब्लैकलिस्ट का उपयोग करके प्रक्रिया को नियंत्रित करने का विकल्प होता है। इस ब्लॉग पोस्ट में, हम आपको कुछ उदाहरण दिखाना चाहते हैं कि आप मास्टर उम्मीदवारों को चुनने के लिए ClusterControl के एल्गोरिदम को कैसे प्रभावित कर सकते हैं।
श्वेतसूची और ब्लैकलिस्ट कॉन्फ़िगरेशन
ClusterControl आपको प्रतिकृतियों की श्वेतसूची और काली सूची दोनों को परिभाषित करने का विकल्प देता है। श्वेतसूची प्रतिकृतियों की एक सूची है जिसका उद्देश्य मास्टर उम्मीदवार बनना है। यदि उनमें से कोई भी उपलब्ध नहीं है (या तो क्योंकि वे नीचे हैं, या गलत लेनदेन हैं, या ऐसी अन्य बाधाएं हैं जो उनमें से किसी को भी पदोन्नत होने से रोकती हैं), विफलता नहीं की जाएगी। इस तरह, आप परिभाषित कर सकते हैं कि मास्टर उम्मीदवार बनने के लिए कौन से होस्ट उपलब्ध हैं। दूसरी ओर, काली सूची में यह परिभाषित किया जाता है कि कौन सी प्रतिकृतियां मास्टर उम्मीदवार बनने के लिए उपयुक्त नहीं हैं।
उन दोनों सूचियों को किसी दिए गए क्लस्टर के लिए cmon कॉन्फ़िगरेशन फ़ाइल में परिभाषित किया जा सकता है। उदाहरण के लिए, यदि आपके क्लस्टर में '1' की आईडी है, तो आप '/etc/cmon.d/cmon_1.cnf' को संपादित करना चाहते हैं। श्वेतसूची के लिए आप 'replication_failover_whitelist' वैरिएबल का उपयोग करेंगे, ब्लैकलिस्ट के लिए यह एक 'replication_failover_blacklist' होगा। दोनों 'होस्ट:पोर्ट' की अल्पविराम से अलग की गई सूची को स्वीकार करते हैं।
आइए निम्नलिखित प्रतिकृति सेटअप पर विचार करें। हमारे पास एक सक्रिय मास्टर (10.0.0.141) है जिसमें दो प्रतिकृतियां (10.0.0.142 और 10.0.0.143) हैं, दोनों मध्यवर्ती स्वामी के रूप में कार्य करते हैं और प्रत्येक की एक प्रतिकृति (10.0.0.144 और 10.0.0.147) है। हमारे पास एक अलग डेटासेंटर (10.0.0.145) में एक स्टैंडबाय मास्टर भी है जिसमें एक प्रतिकृति (10.0.0.146) है। आपदा के मामले में उन मेजबानों का उपयोग करने का इरादा है। प्रतिकृतियां 10.0.0.146 और 10.0.0.147 बैकअप होस्ट के रूप में कार्य करती हैं। नीचे स्क्रीनशॉट देखें।
यह देखते हुए कि दूसरा डेटासेंटर केवल आपदा पुनर्प्राप्ति के लिए है, हम नहीं चाहते कि उनमें से किसी भी होस्ट को मास्टर के रूप में पदोन्नत किया जाए। सबसे खराब स्थिति में, हम मैन्युअल कार्रवाई करेंगे। दूसरे डेटासेंटर के बुनियादी ढांचे को उत्पादन डेटासेंटर के आकार में नहीं बढ़ाया गया है (डीआर डेटासेंटर में तीन प्रतिकृतियां कम हैं), इसलिए डीआर डेटासेंटर में एक होस्ट को बढ़ावा देने से पहले वैसे भी मैन्युअल क्रियाओं की आवश्यकता होती है। हम यह भी नहीं चाहेंगे कि एक बैकअप प्रतिकृति (10.0.0.147) को बढ़ावा दिया जाए। न तो हम चाहते हैं कि श्रृंखला में तीसरी प्रतिकृति को मास्टर के रूप में लिया जाए (भले ही यह GTID के साथ किया जा सकता है)।
श्वेतसूची कॉन्फ़िगरेशन
हम यह सुनिश्चित करने के लिए श्वेतसूची या ब्लैकलिस्ट को कॉन्फ़िगर कर सकते हैं कि विफलता को हमारी पसंद के अनुसार नियंत्रित किया जाएगा। इस विशेष सेटअप में, श्वेतसूची का उपयोग करना अधिक उपयुक्त हो सकता है - हम परिभाषित करेंगे कि कौन से होस्ट का उपयोग विफलता के लिए किया जा सकता है और यदि कोई सेटअप में एक नया होस्ट जोड़ता है, तो इसे मास्टर उम्मीदवार के रूप में तब तक नहीं माना जाएगा जब तक कि कोई इसे मैन्युअल रूप से तय नहीं करेगा। इसका उपयोग करना और इसे श्वेतसूची में जोड़ना ठीक है। यदि हम ब्लैकलिस्ट का उपयोग करते हैं, तो श्रृंखला में कहीं नई प्रतिकृति जोड़ने का मतलब यह हो सकता है कि ऐसी प्रतिकृति सैद्धांतिक रूप से स्वचालित रूप से विफलता के लिए उपयोग की जा सकती है जब तक कि कोई स्पष्ट रूप से यह न कहे कि इसका उपयोग नहीं किया जा सकता है। आइए सुरक्षित पक्ष पर रहें और हमारी क्लस्टर कॉन्फ़िगरेशन फ़ाइल में एक श्वेतसूची को परिभाषित करें (इस मामले में यह /etc/cmon.d/cmon_1.cnf है क्योंकि हमारे पास सिर्फ एक क्लस्टर है):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306हमें यह सुनिश्चित करना होगा कि परिवर्तन लागू करने के लिए सीमोन प्रक्रिया को फिर से शुरू किया गया है:
service cmon restartआइए मान लें कि हमारा मास्टर क्रैश हो गया है और क्लस्टर कंट्रोल द्वारा नहीं पहुंचा जा सकता है। एक असफल कार्य शुरू किया जाएगा:
टोपोलॉजी नीचे की तरह दिखेगी:
जैसा कि आप देख सकते हैं, पुराना मास्टर अक्षम है और ClusterControl इसे स्वचालित रूप से पुनर्प्राप्त करने का प्रयास नहीं करेगा। यह उपयोगकर्ता पर निर्भर करता है कि क्या हुआ है, किसी भी डेटा को कॉपी करें जिसे मास्टर उम्मीदवार को दोहराया नहीं गया हो और पुराने मास्टर का पुनर्निर्माण करें:
फिर यह कुछ टोपोलॉजी परिवर्तनों की बात है और हम टोपोलॉजी को मूल स्थिति में ला सकते हैं, बस 10.0.0.141 को 10.0.0.142 से बदल दें:
ब्लैकलिस्ट कॉन्फ़िगरेशन
अब हम यह देखने जा रहे हैं कि ब्लैक लिस्ट कैसे काम करती है। हमने उल्लेख किया है कि, हमारे उदाहरण में, यह सबसे अच्छा विकल्प नहीं हो सकता है, लेकिन हम इसे उदाहरण के लिए आजमाएंगे। हम 10.0.0.141, 10.0.0.142 और 10.0.0.143 को छोड़कर प्रत्येक होस्ट को ब्लैकलिस्ट करेंगे क्योंकि वे होस्ट हैं जिन्हें हम मास्टर उम्मीदवारों के रूप में देखना चाहते हैं।
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306हम कॉन्फ़िगरेशन परिवर्तन लागू करने के लिए सीमोन प्रक्रिया को भी पुनः आरंभ करेंगे:
service cmon restartविफलता प्रक्रिया समान है। एक बार फिर, मास्टर क्रैश का पता चलने के बाद, ClusterControl एक फ़ेलओवर कार्य प्रारंभ कर देगा।
जब एक प्रतिकृति एक अच्छा मास्टर उम्मीदवार नहीं हो सकता है
इस संक्षिप्त खंड में, हम कुछ ऐसे मामलों के बारे में अधिक विस्तार से चर्चा करना चाहेंगे जिनमें आप एक नई मास्टर बनने के लिए किसी दी गई प्रतिकृति को बढ़ावा नहीं देना चाहते हैं। उम्मीद है, यह आपको उन मामलों के बारे में कुछ विचार देगा जहां आपको फ़ेलओवर प्रक्रिया के अधिक मैन्युअल नियंत्रण को प्रेरित करने पर विचार करने की आवश्यकता हो सकती है।
विभिन्न MySQL संस्करण
सबसे पहले, यदि आपकी प्रतिकृति मास्टर की तुलना में एक अलग MySQL संस्करण का उपयोग करती है, तो इसे बढ़ावा देना एक अच्छा विचार नहीं है। सामान्यतया, अधिक हाल का संस्करण हमेशा नो-गो होता है क्योंकि नए से पुराने MySQL संस्करण में प्रतिकृति समर्थित नहीं है और ठीक से काम नहीं कर सकता है। यह ज्यादातर प्रमुख संस्करणों के लिए प्रासंगिक है (उदाहरण के लिए, 8.0 से 5.7 की प्रतिकृति) लेकिन अच्छा अभ्यास इस सेटअप से पूरी तरह से बचना है, भले ही हम छोटे संस्करण अंतर (5.7.x+1 -> 5.7.x) के बारे में बात कर रहे हों। निम्न से उच्चतर/नए संस्करण में प्रतिकृति का समर्थन किया जाता है क्योंकि यह अपग्रेड प्रक्रिया के लिए आवश्यक है, लेकिन फिर भी, आप इससे बचना चाहेंगे (उदाहरण के लिए, यदि आपका मास्टर 5.7.x+1 पर है, तो आप इसे प्रतिस्थापित नहीं करना चाहेंगे) 5.7.x पर एक प्रतिकृति के साथ)।
विभिन्न भूमिकाएं
आप अपनी प्रतिकृतियों को अलग-अलग भूमिकाएँ सौंप सकते हैं। आप उत्पादन डेटासेट पर उनके प्रश्नों का परीक्षण करने के लिए डेवलपर्स के लिए उपलब्ध होने के लिए उनमें से एक को चुन सकते हैं। आप उनमें से किसी एक का उपयोग OLAP कार्यभार के लिए कर सकते हैं। आप बैकअप के लिए उनमें से किसी एक का उपयोग कर सकते हैं। कोई फर्क नहीं पड़ता कि यह क्या है, आम तौर पर आप ऐसी प्रतिकृति को मास्टर में बढ़ावा नहीं देना चाहेंगे। वे सभी अतिरिक्त, गैर-मानक कार्यभार अतिरिक्त ओवरहेड के कारण प्रदर्शन समस्याओं का कारण बन सकते हैं। एक मास्टर उम्मीदवार के लिए एक अच्छा विकल्प एक प्रतिकृति है जो "सामान्य" भार को संभाल रहा है, कमोबेश उसी प्रकार का भार जो वर्तमान मास्टर के रूप में है। फिर आप निश्चित हो सकते हैं कि अगर यह इससे पहले इसे संभालता है तो यह विफलता के बाद मास्टर लोड को संभाल लेगा।
विभिन्न हार्डवेयर विनिर्देश
हमने प्रतिकृतियों के लिए विभिन्न भूमिकाओं का उल्लेख किया है। विभिन्न हार्डवेयर विशिष्टताओं को भी देखना असामान्य नहीं है, विशेष रूप से विभिन्न भूमिकाओं के संयोजन में। उदाहरण के लिए, एक बैकअप दास को नियमित प्रतिकृति के रूप में शक्तिशाली होने की संभावना नहीं है। डेवलपर्स उत्पादन की तुलना में धीमे डेटाबेस पर अपने प्रश्नों का परीक्षण भी कर सकते हैं (ज्यादातर इसलिए कि आप विकास और उत्पादन डेटाबेस पर समान स्तर की समरूपता की अपेक्षा नहीं करेंगे) और, उदाहरण के लिए, सीपीयू कोर गिनती को कम किया जा सकता है। डिजास्टर रिकवरी सेटअप को आकार में भी कम किया जा सकता है यदि उनकी मुख्य भूमिका प्रतिकृति के साथ बनाए रखने की होगी और यह उम्मीद की जाती है कि DR सेटअप को बढ़ाया जाना होगा (दोनों लंबवत, उदाहरण को आकार देकर और क्षैतिज रूप से, अधिक प्रतिकृतियां जोड़कर) इससे पहले कि यातायात को उस पर पुनर्निर्देशित किया जा सके।
विलंबित प्रतिकृतियां
कुछ प्रतिकृतियों में देरी हो सकती है - यदि डेटा खो गया है तो यह पुनर्प्राप्ति समय को कम करने का एक बहुत अच्छा तरीका है, लेकिन यह उन्हें बहुत खराब मास्टर उम्मीदवार बनाता है। यदि एक प्रतिकृति में 30 मिनट की देरी होती है, तो आप या तो 30 मिनट के लेन-देन को खो देंगे या आपको सभी विलंबित लेनदेन को लागू करने के लिए प्रतिकृति के लिए प्रतीक्षा करनी होगी (शायद 30 मिनट नहीं, सबसे अधिक संभावना है, प्रतिकृति तेजी से पकड़ सकती है)। ClusterControl आपको यह चुनने की अनुमति देता है कि क्या आप प्रतीक्षा करना चाहते हैं या यदि आप तुरंत विफल होना चाहते हैं, लेकिन यह बहुत छोटे अंतराल के लिए ठीक काम करेगा - अधिकतम दस सेकंड। अगर फ़ेलओवर में कुछ मिनट लगते हैं, तो ऐसी प्रतिकृति का उपयोग करने का कोई मतलब नहीं है और इसलिए इसे ब्लैकलिस्ट करना एक अच्छा विचार है।
विभिन्न डेटासेंटर
हमने स्केल-डाउन DR सेटअप का उल्लेख किया है, लेकिन भले ही आपका दूसरा डेटासेंटर उत्पादन के आकार के लिए बढ़ाया गया हो, फिर भी फ़ेलओवर को केवल एक DC के भीतर रखना एक अच्छा विचार हो सकता है। शुरुआत के लिए, आपके सक्रिय एप्लिकेशन होस्ट मुख्य डेटासेंटर में स्थित हो सकते हैं, इस प्रकार मास्टर को स्टैंडबाय डीसी में ले जाने से प्रश्नों को लिखने के लिए विलंबता में काफी वृद्धि होगी। साथ ही, नेटवर्क विभाजन के मामले में, आप इस स्थिति को मैन्युअल रूप से संभालना चाह सकते हैं। MySQL में एक कोरम तंत्र नहीं बनाया गया है इसलिए दो डेटासेंटर के बीच नेटवर्क हानि को सही ढंग से (स्वचालित तरीके से) संभालना मुश्किल है।
