भाग I में, हमने MySQL होस्टिंग के लिए एक उच्च उपलब्धता (HA) फ्रेमवर्क पेश किया और विभिन्न घटकों और उनकी कार्यक्षमता पर चर्चा की। अब भाग II में, हम MySQL सेमीसिंक्रोनस प्रतिकृति और संबंधित कॉन्फ़िगरेशन सेटिंग्स के विवरण पर चर्चा करेंगे जो हमारे HA सेटअप में डेटा की अतिरेक और स्थिरता सुनिश्चित करने में हमारी सहायता करते हैं। भाग III के लिए वापस चेक इन करना सुनिश्चित करें जहां हम विभिन्न विफलता परिदृश्यों की समीक्षा करेंगे जो उत्पन्न हो सकते हैं और जिस तरह से ढांचा इन स्थितियों से प्रतिक्रिया करता है और ठीक हो जाता है।
MySQL सेमीसिंक्रोनस प्रतिकृति क्या है?
सीधे शब्दों में कहें, MySQL सेमीसिंक्रोनस प्रतिकृति कॉन्फ़िगरेशन में, मास्टर कम से कम एक दास से पावती प्राप्त करने के बाद ही स्टोरेज इंजन में लेनदेन करता है। घटनाओं को प्राप्त करने और रिले लॉग में कॉपी करने और डिस्क पर फ्लश करने के बाद ही दास पावती प्रदान करेंगे। यह गारंटी देता है कि क्लाइंट को किए गए और वापस किए गए सभी लेनदेन के लिए, डेटा कम से कम 2 नोड्स पर मौजूद है। सेमीसिंक्रोनस (प्रतिकृति) में शब्द 'सेमी' इस तथ्य के कारण है कि मास्टर एक बार घटनाओं को प्राप्त करने और रिले लॉग में फ्लश करने के बाद लेनदेन करता है, लेकिन जरूरी नहीं कि दास पर डेटा फ़ाइलों के लिए प्रतिबद्ध हो। यह पूरी तरह से सिंक्रोनस प्रतिकृति के विपरीत है, जहां क्लाइंट को सत्र वापस आने से पहले लेन-देन दास और मास्टर दोनों पर किया गया होगा।
सेमीसिंक्रोनस प्रतिकृति, जो मूल रूप से MySQL में उपलब्ध है, प्रतिबद्ध लेनदेन के लिए डेटा स्थिरता और अतिरेक सुनिश्चित करने के लिए HA फ्रेमवर्क की मदद करता है। मास्टर विफलता की स्थिति में, मास्टर पर किए गए सभी लेन-देन को कम से कम एक दास (रिले लॉग में सहेजा गया) में दोहराया गया होगा। परिणामस्वरूप, उस दास की विफलता दोषरहित होगी क्योंकि दास अद्यतित है (दास के रिले लॉग पूरी तरह से समाप्त हो जाने के बाद)।
प्रतिकृति और सेमीसिंक्रोनस संबंधित सेटिंग्स
आइए कुछ प्रमुख MySQL सेटिंग्स पर चर्चा करते हैं जो हमारे ढांचे में उच्च उपलब्धता और डेटा स्थिरता के लिए इष्टतम व्यवहार सुनिश्चित करने के लिए उपयोग की जाती हैं।
दासों की निष्पादन गति को प्रबंधित करना
पहला विचार सेमीसिंक्रोनस प्रतिकृति के 'अर्ध' व्यवहार को संभालना है जो केवल गारंटी देता है कि डेटा प्राप्त किया गया है और I/O थ्रेड द्वारा रिले लॉग में फ़्लश किया गया है गुलाम, लेकिन जरूरी नहीं कि SQL थ्रेड द्वारा प्रतिबद्ध हो। डिफ़ॉल्ट रूप से, MySQL स्लेव में SQL थ्रेड सिंगल-थ्रेडेड होता है और मास्टर के साथ तालमेल नहीं रख पाएगा जो मल्टी-थ्रेडेड है। इसका स्पष्ट प्रभाव यह है कि मास्टर विफलता की स्थिति में, दास अप-टू-डेट नहीं होगा क्योंकि इसका SQL थ्रेड अभी भी रिले लॉग में घटनाओं को संसाधित कर रहा है। यह विफलता प्रक्रिया में देरी करेगा क्योंकि हमारे ढांचे को उम्मीद है कि दास को बढ़ावा देने से पहले पूरी तरह से अद्यतित हो जाएगा। डेटा स्थिरता बनाए रखने के लिए यह आवश्यक है। इस समस्या का समाधान करने के लिए, हम विकल्प के साथ बहु-थ्रेडेड स्लेव को सक्षम करते हैं, ताकि रिले लॉग में ईवेंट को संसाधित करने के लिए समानांतर SQL थ्रेड्स की संख्या निर्धारित की जा सके।
इसके अलावा, हम नीचे दी गई सेटिंग्स को कॉन्फ़िगर करते हैं जो सुनिश्चित करती हैं कि दास किसी भी स्थिति में प्रवेश नहीं करता है जिसमें मास्टर नहीं था:
- गुलाम-समानांतर-प्रकार =LOGICAL_CLOCK
- slave_preserve_commit_order =1
यह हमें मजबूत डेटा स्थिरता प्रदान करता है। इन सेटिंग्स के साथ, हम दास पर बेहतर समांतरता और गति प्राप्त करने में सक्षम होंगे, लेकिन यदि बहुत अधिक समानांतर धागे हैं, तो धागे के बीच समन्वय में शामिल ओवरहेड भी बढ़ जाएगा और दुर्भाग्य से लाभों को ऑफसेट कर सकता है।
एक अन्य कॉन्फ़िगरेशन जिसका उपयोग हम दासों पर समानांतर निष्पादन की दक्षता बढ़ाने के लिए कर सकते हैं, वह है मास्टर पर binlog_group_commit_sync_delay को ट्यून करना। इसे मास्टर पर सेट करके, मास्टर पर बाइनरी लॉग प्रविष्टियाँ और इसलिए दास पर रिले लॉग प्रविष्टियों में लेन-देन के बैच होंगे जिन्हें SQL थ्रेड्स द्वारा समानांतर रूप से संसाधित किया जा सकता है। इसे जे-एफ गग्ने के ब्लॉग में विस्तार से समझाया गया है जहां उन्होंने इस व्यवहार को 'दास को गति देने के लिए मास्टर को धीमा करना' के रूप में संदर्भित किया है। ।
यदि आप स्केलग्रिड कंसोल के माध्यम से अपने MySQL परिनियोजन का प्रबंधन कर रहे हैं, तो आपके पास दासों के प्रतिकृति अंतराल पर निरंतर निगरानी और रीयल-टाइम अलर्ट प्राप्त करने की क्षमता है। यह आपको उपरोक्त मापदंडों को गतिशील रूप से ट्यून करने की अनुमति देता है ताकि यह सुनिश्चित हो सके कि दास मास्टर के साथ हाथ से काम कर रहे हैं, इसलिए, एक विफलता प्रक्रिया में शामिल आपके समय को कम करते हैं।
MySQL उच्च उपलब्धता फ्रेमवर्क समझाया गया - भाग IIट्वीट करने के लिए क्लिक करें
महत्वपूर्ण सेमीसिंक्रोनस प्रतिकृति विकल्प
MySQL सेमीसिंक्रोनस प्रतिकृति, डिज़ाइन द्वारा, स्लेव पावती टाइमआउट सेटिंग्स के आधार पर या किसी भी समय उपलब्ध सेमीसिंक्रोनस-सक्षम दासों की संख्या के आधार पर एसिंक्रोनस मोड में वापस आ सकती है। एसिंक्रोनस मोड, परिभाषा के अनुसार, गारंटी प्रदान नहीं करता है कि प्रतिबद्ध लेनदेन दास को दोहराए जाते हैं और इसलिए एक मास्टर नुकसान से उस डेटा को खो दिया जाएगा जिसे दोहराया नहीं गया है। स्केलग्रिड HA फ्रेमवर्क का डिफ़ॉल्ट डिज़ाइन एसिंक्रोनस मोड में वापस आने से बचने के लिए है। आइए इस व्यवहार को प्रभावित करने वाले कॉन्फ़िगरेशन की समीक्षा करें।
-
rpl_semi_sync_master_wait_for_slave_count
इस विकल्प का उपयोग उन दासों की संख्या को कॉन्फ़िगर करने के लिए किया जाता है, जिन्हें एक सेमीसिंक्रोनस मास्टर द्वारा लेन-देन करने से पहले एक पावती भेजनी होगी। 3-नोड मास्टर-स्लेव कॉन्फ़िगरेशन में, हम इसे 1 पर सेट करते हैं, इसलिए हमें हमेशा यह आश्वासन मिलता है कि डेटा कम से कम एक स्लेव में उपलब्ध है, जबकि दोनों स्लेव से पावती की प्रतीक्षा में शामिल किसी भी प्रदर्शन प्रभाव से बचने के लिए।
-
rpl_semi_sync_master_timeout
इस विकल्प का उपयोग उस समय की मात्रा को कॉन्फ़िगर करने के लिए किया जाता है, जब एक सेमीसिंक्रोनस मास्टर एसिंक्रोनस मोड पर वापस जाने से पहले एक गुलाम से पावती की प्रतीक्षा करता है। हम इसे अपेक्षाकृत उच्च टाइमआउट मान पर सेट करते हैं ताकि एसिंक्रोनस मोड में कोई वापसी न हो।
चूंकि हम 2 दासों के साथ काम कर रहे हैं और rpl_semi_sync_master_wait_for_slave_count 1 पर सेट है, हमने देखा है कि कम से कम एक दास उचित समय के भीतर स्वीकार करता है और मास्टर अस्थायी नेटवर्क व्यवधानों के दौरान एसिंक्रोनस मोड पर स्विच नहीं करता है।
-
rpl_semi_sync_master_wait_no_slave
यह नियंत्रित करता है कि मास्टर rpl_semi_sync_master_timeout द्वारा कॉन्फ़िगर की गई टाइमआउट अवधि के समाप्त होने की प्रतीक्षा करता है या नहीं, भले ही स्लेव की संख्या टाइमआउट अवधि के दौरान rpl_semi_sync_master_wait_for_slave_count द्वारा कॉन्फ़िगर किए गए स्लेवों की संख्या से कम हो जाए। हम ON के डिफ़ॉल्ट मान को बनाए रखते हैं ताकि मास्टर एसिंक्रोनस प्रतिकृति पर वापस न आए।
सभी अर्धतुल्यकाली दासों को खोने का प्रभाव
जैसा कि हमने ऊपर देखा, हमारा ढांचा मास्टर को एसिंक्रोनस प्रतिकृति पर स्विच करने से रोकता है यदि सभी दास नीचे जाते हैं या मास्टर से पहुंच से बाहर हो जाते हैं। इसका सीधा असर यह होता है कि मास्टर पर राइट्स रुक जाते हैं जिससे सर्विस की उपलब्धता प्रभावित होती है। यह अनिवार्य रूप से किसी भी वितरित प्रणाली की सीमाओं के बारे में सीएपी प्रमेय द्वारा वर्णित है। प्रमेय में कहा गया है कि, नेटवर्क विभाजन की उपस्थिति में, हमें या तो उपलब्धता या स्थिरता को चुनना होगा, लेकिन दोनों को नहीं। इस मामले में, नेटवर्क विभाजन को मास्टर से डिस्कनेक्ट किए गए MySQL दास के रूप में माना जा सकता है क्योंकि वे या तो नीचे हैं या पहुंच से बाहर हैं।
हमारा निरंतरता लक्ष्य यह सुनिश्चित करना है कि सभी प्रतिबद्ध लेनदेन के लिए, डेटा कम से कम 2 नोड्स पर उपलब्ध हो। ऐसे मामलों के परिणामस्वरूप, स्केलग्रिड एचए ढांचा उपलब्धता पर स्थिरता का पक्षधर है। आगे के लेखन ग्राहकों से स्वीकार नहीं किए जाएंगे, हालांकि MySQL मास्टर अभी भी पढ़ने के अनुरोधों की सेवा करेगा। यह एक सचेत डिज़ाइन निर्णय है जिसे हमने डिफ़ॉल्ट व्यवहार के रूप में लिया है, जो निश्चित रूप से, एप्लिकेशन आवश्यकताओं के आधार पर कॉन्फ़िगर करने योग्य है।
स्केलग्रिड ब्लॉग की सदस्यता लेना सुनिश्चित करें ताकि आप भाग III को याद न करें जहां हम MySQL HA फ्रेमवर्क की अधिक विफलता परिदृश्यों और पुनर्प्राप्ति क्षमताओं पर चर्चा करेंगे। . बने रहें!!
