MySQL प्रतिकृति सर्वोत्तम अभ्यास

MySQL प्रतिकृति जीथब, ट्विटर और फेसबुक जैसे विशाल संगठनों द्वारा उच्च उपलब्धता के लिए सबसे आम और व्यापक रूप से उपयोग किया जाने वाला समाधान रहा है। हालांकि स्थापित करना आसान है, रखरखाव से इस समाधान का उपयोग करते समय चुनौतियों का सामना करना पड़ता है, जिसमें सॉफ़्टवेयर अपग्रेड, डेटा बहाव या प्रतिकृति नोड्स में डेटा असंगति, टोपोलॉजी परिवर्तन, विफलता और पुनर्प्राप्ति शामिल है। जब MySQL ने संस्करण 5.6 जारी किया, तो इसने कई महत्वपूर्ण संवर्द्धन लाए, विशेष रूप से प्रतिकृति के लिए जिसमें ग्लोबल ट्रांजैक्शन आईडी (GTID), इवेंट चेकसम, मल्टी-थ्रेडेड स्लेव और क्रैश-सेफ स्लेव / मास्टर्स शामिल हैं। MySQL 5.7 और MySQL 8.0 के साथ प्रतिकृति और भी बेहतर हो गई है।

प्रतिकृति एक MySQL सर्वर (प्राथमिक/मास्टर) से डेटा को एक या अधिक MySQL सर्वर (प्रतिकृति/दास) में दोहराने के लिए सक्षम बनाता है। MySQL प्रतिकृति को स्थापित करना बहुत आसान है और इसका उपयोग रीड वर्कलोड को कम करने, उच्च उपलब्धता और भौगोलिक अतिरेक, और ऑफलोड बैकअप और विश्लेषणात्मक कार्य प्रदान करने के लिए किया जाता है।

प्रकृति में MySQL प्रतिकृति

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

• प्राथमिक एक प्रतिकृति की प्रतीक्षा नहीं करता है।

• प्रतिकृति निर्धारित करती है कि बाइनरी लॉग में कितना पढ़ना है और किस बिंदु से।

• प्रतिलिपि मनमाने ढंग से परिवर्तनों को पढ़ने या लागू करने में मास्टर के पीछे हो सकती है।

यदि प्राथमिक क्रैश हो जाता है, तो हो सकता है कि इसके द्वारा किए गए लेन-देन किसी प्रतिकृति को प्रेषित न किए गए हों। नतीजतन, प्राथमिक से सबसे उन्नत प्रतिकृति में विफलता, इस मामले में, वांछित प्राथमिक में विफलता का परिणाम हो सकता है जो वास्तव में पिछले सर्वर के सापेक्ष लेनदेन गायब है।

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

MySQL सेमी-सिंक्रोनस प्रतिकृति

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

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

प्रतिकृति प्रारूप का गलत उपयोग करना

MySQL 5.7.7 के बाद से, डिफ़ॉल्ट बाइनरी लॉग फॉर्मेट या binlog_format वैरिएबल ROW का उपयोग करता है, जो कि 5.7.7 से पहले STATEMENT था। विभिन्न प्रतिकृति प्रारूप स्रोत की बाइनरी लॉग घटनाओं को रिकॉर्ड करने के लिए उपयोग की जाने वाली विधि से मेल खाते हैं। प्रतिकृति काम करती है क्योंकि बाइनरी लॉग में लिखी गई घटनाओं को स्रोत से पढ़ा जाता है और फिर प्रतिकृति पर संसाधित किया जाता है। घटना के प्रकार के अनुसार अलग-अलग प्रतिकृति स्वरूपों में बाइनरी लॉग के भीतर घटनाओं को रिकॉर्ड किया जाता है। निश्चित रूप से नहीं जानना कि क्या उपयोग करना एक समस्या हो सकती है। MySQL में प्रतिकृति विधियों के तीन प्रारूप हैं:STATEMENT, ROW, और MIXED।

• स्टेटमेंट-आधारित प्रतिकृति (एसबीआर) प्रारूप ठीक वैसा ही है जैसा वह है-प्रत्येक स्टेटमेंट रन की एक प्रतिकृति स्ट्रीम मास्टर पर जो दास नोड पर फिर से चलाया जाएगा। डिफ़ॉल्ट रूप से, MySQL पारंपरिक (एसिंक्रोनस) प्रतिकृति समानांतर में दासों को दोहराए गए लेनदेन को निष्पादित नहीं करता है। इसका मतलब है कि प्रतिकृति धारा में बयानों का क्रम 100% समान नहीं हो सकता है। साथ ही, एक स्टेटमेंट को फिर से चलाने से अलग-अलग परिणाम मिल सकते हैं जब एक ही समय में निष्पादित नहीं किया जाता है जब स्रोत से निष्पादित किया जाता है। यह प्राथमिक और इसकी प्रतिकृति के विरुद्ध असंगत स्थिति की ओर ले जाता है। यह कई वर्षों तक कोई समस्या नहीं थी, क्योंकि कई एक साथ कई थ्रेड्स के साथ MySQL नहीं चलाते थे। हालांकि, आधुनिक मल्टी-सीपीयू आर्किटेक्चर के साथ, यह वास्तव में सामान्य दिन-प्रतिदिन के कार्यभार पर अत्यधिक संभावित हो गया है।

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

• फिर इन दोनों के बीच एक विधि है; मिश्रित मोड प्रतिकृति। इस प्रकार की प्रतिकृति हमेशा बयानों को दोहराएगी, सिवाय इसके कि जब क्वेरी में UUID () फ़ंक्शन, ट्रिगर, संग्रहीत कार्यविधियाँ, UDF और कुछ अन्य अपवाद हों। मिश्रित-मोड डेटा बहाव के मुद्दे को हल नहीं करेगा और, कथन-आधारित प्रतिकृति के साथ, इससे बचा जाना चाहिए।

मल्टी-मास्टर सेटअप की योजना बना रहे हैं?

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

हालांकि, यदि आपको एक ही डेटाबेस में एकाधिक डेटा केंद्रों में लिखने की आवश्यकता है , आप कई मास्टर्स के साथ समाप्त होते हैं जिन्हें एक दूसरे को अपना डेटा लिखने की आवश्यकता होती है। MySQL 5.7.6 से पहले, जाल प्रकार की प्रतिकृति करने की कोई विधि नहीं थी, इसलिए विकल्प इसके बजाय एक गोलाकार रिंग प्रतिकृति का उपयोग करना होगा।

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

सामान्य तौर पर, सर्कुलर प्रतिकृति MySQL के लिए उपयुक्त नहीं है और इसे होना चाहिए हर कीमत पर टाला। जैसा कि इसे ध्यान में रखकर डिजाइन किया गया था, गैलेरा क्लस्टर मल्टी-डेटासेंटर राइट्स के लिए एक अच्छा विकल्प होगा।

बड़े अपडेट के साथ अपनी प्रतिकृति को रोकना

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

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

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

इसके समाधान के लिए, MariaDB और MySQL दोनों समानांतर प्रतिकृति प्रदान करते हैं। कार्यान्वयन प्रति विक्रेता और संस्करण भिन्न हो सकता है। MySQL 5.6 समानांतर प्रतिकृति प्रदान करता है जब तक कि स्कीमा द्वारा प्रश्नों को अलग किया जाता है। मारियाडीबी 10.0 और माईएसक्यूएल 5.7 दोनों स्कीमा में समानांतर प्रतिकृति को संभाल सकते हैं लेकिन अन्य सीमाएं हैं। यदि आप भारी लिख रहे हैं, तो समानांतर स्लेव थ्रेड्स के माध्यम से प्रश्नों को निष्पादित करने से आपकी प्रतिकृति स्ट्रीम में तेजी आ सकती है। अन्यथा, पारंपरिक सिंगल-थ्रेड प्रतिकृति से चिपके रहना बेहतर होगा।

अपनी स्कीमा परिवर्तन या DDL को संभालना

5.7 की रिलीज़ के बाद से, MySQL में स्कीमा परिवर्तन या DDL (डेटा परिभाषा भाषा) परिवर्तन के प्रबंधन में बहुत सुधार हुआ है। MySQL 8.0 तक, DDL समर्थित एल्गोरिथम परिवर्तन COPY और INPLACE हैं।

• COPY:यह एल्गोरिथम परिवर्तित स्कीमा के साथ एक नई अस्थायी तालिका बनाता है। एक बार जब यह डेटा को पूरी तरह से नई अस्थायी तालिका में स्थानांतरित कर देता है, तो यह पुरानी तालिका को बदल देता है और छोड़ देता है।

• INPLACE:यह एल्गोरिथम मूल तालिका के स्थान पर संचालन करता है और जब भी संभव हो, तालिका की प्रतिलिपि और पुनर्निर्माण से बचा जाता है।

• झटपट:यह एल्गोरिथम MySQL 8.0 से शुरू किया गया है लेकिन अभी भी इसकी सीमाएं हैं।

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

हालांकि यह एक आशाजनक सुधार है, फिर भी उनके साथ सीमाएं हैं, और कभी-कभी उन तत्काल और लागू एल्गोरिदम को लागू करना संभव नहीं होता है। उदाहरण के लिए, INSTANT और INPLACE एल्गोरिदम के लिए, कॉलम के डेटा प्रकार को बदलना भी एक सामान्य DBA कार्य है, विशेष रूप से डेटा परिवर्तन के कारण अनुप्रयोग विकास परिप्रेक्ष्य में। ये अवसर अपरिहार्य हैं; इस प्रकार, आप COPY एल्गोरिथम के साथ नहीं जा सकते क्योंकि यह तालिका को लॉक कर देता है जिससे दास में देरी होती है। यह इस निष्पादन के दौरान प्राथमिक/मास्टर सर्वर को भी प्रभावित करता है क्योंकि यह आने वाले लेन-देन को ढेर करता है जो प्रभावित तालिका को भी संदर्भित करता है। आप व्यस्त सर्वर पर सीधे ALTER या स्कीमा परिवर्तन नहीं कर सकते क्योंकि यह डाउनटाइम के साथ आता है या संभवतः आपके डेटाबेस को दूषित कर देता है यदि आप धैर्य खो देते हैं, खासकर यदि लक्ष्य तालिका बहुत बड़ी है।

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

ऐसे उपकरण उपलब्ध हैं जो ऑनलाइन स्कीमा परिवर्तन अधिक विश्वसनीय ढंग से कर सकते हैं। Schlomi Noach द्वारा Percona Online Schema Change (जैसा कि pt-osc के रूप में जाना जाता है) और gh-ost आमतौर पर DBA द्वारा उपयोग किया जाता है। ये उपकरण प्रभावित पंक्तियों को विखंडू में समूहित करके स्कीमा परिवर्तनों को प्रभावी ढंग से संभालते हैं, और आप कितने समूह बनाना चाहते हैं, इसके आधार पर इन विखंडू को तदनुसार कॉन्फ़िगर किया जा सकता है।

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

gh-ost का उपयोग करने से पहले आपके मौजूदा टेबल लेआउट की एक कॉपी बन जाएगी, तालिका को नए लेआउट में बदलें, और फिर प्रक्रिया को एक MySQL प्रतिकृति के रूप में हुक करें। यह मूल तालिका में डाली गई नई पंक्तियों को खोजने के लिए प्रतिकृति स्ट्रीम का उपयोग करेगा और साथ ही, तालिका को बैकफ़िल भी करेगा। एक बार जब यह बैकफिलिंग हो जाता है, तो मूल और नई टेबल स्विच हो जाएंगी। स्वाभाविक रूप से, नई तालिका के सभी ऑपरेशन प्रतिकृति स्ट्रीम में समाप्त हो जाएंगे; इस प्रकार, प्रत्येक प्रतिकृति पर, माइग्रेशन एक साथ होता है।

स्मृति तालिकाएं और प्रतिकृति

जबकि हम डीडीएल के विषय पर हैं, स्मृति तालिकाओं का निर्माण एक सामान्य समस्या है। मेमोरी टेबल गैर-निरंतर टेबल हैं, उनकी टेबल संरचना बनी रहती है, लेकिन वे MySQL के पुनरारंभ होने के बाद अपना डेटा खो देते हैं। मास्टर और गुलाम दोनों पर एक नई मेमोरी टेबल बनाते समय, उनके पास एक खाली टेबल होगी, जो पूरी तरह से ठीक काम करेगी। एक बार दोनों में से एक के पुनः आरंभ हो जाने पर, तालिका खाली हो जाएगी, और प्रतिकृति त्रुटियाँ उत्पन्न होंगी।

एक बार जब दास नोड में डेटा अलग-अलग परिणाम देता है, तो पंक्ति-आधारित प्रतिकृति टूट जाएगी, और पहले से मौजूद डेटा को सम्मिलित करने का प्रयास करने पर कथन-आधारित प्रतिकृति टूट जाएगी। मेमोरी टेबल के लिए, यह लगातार प्रतिकृति-ब्रेकर है। फिक्स आसान है:डेटा की एक नई प्रतिलिपि बनाएं, इंजन को InnoDB में बदलें, और यह अब प्रतिकृति सुरक्षित होना चाहिए।

read_only={True|1}

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

इसके लिए आसान रोकथाम यह सुनिश्चित करना है कि केवल read_only और super_read_only (केवल> 5.6 पर) ON या 1 में सेट हैं। आप समझ गए होंगे कि ये दोनों चर कैसे भिन्न हैं और यदि आप अक्षम या सक्षम करते हैं तो यह कैसे प्रभावित होता है। उन्हें। Super_read_only (MySQL 5.7.8 के बाद से) अक्षम होने के साथ, रूट उपयोगकर्ता लक्ष्य या प्रतिकृति में किसी भी बदलाव को रोक सकता है। इसलिए जब दोनों अक्षम हो जाते हैं, तो यह प्रतिकृति को छोड़कर, किसी को भी डेटा में परिवर्तन करने की अनुमति नहीं देगा। अधिकांश फ़ेलओवर प्रबंधक, जैसे कि ClusterControl, इस फ़्लैग को स्वचालित रूप से सेट करते हैं ताकि उपयोगकर्ता फ़ेलओवर के दौरान उपयोग किए गए मास्टर को लिखने से रोक सकें। उनमें से कुछ फेलओवर के बाद भी इसे बरकरार रखते हैं।

GTID सक्षम करना

MySQL प्रतिकृति में, बाइनरी लॉग में दास को सही स्थिति से प्रारंभ करना आवश्यक है। बैकअप बनाते समय इस स्थिति को प्राप्त किया जा सकता है (xtrabackup और mysqldump इसका समर्थन करते हैं) या जब आपने उस नोड पर स्लाव करना बंद कर दिया है जिसकी आप प्रतिलिपि बना रहे हैं। चेंज मास्टर टू कमांड के साथ प्रतिकृति शुरू करना इस तरह दिखेगा:

mysql> CHANGE MASTER TO MASTER_HOST='x.x.x.x',
MASTER_USER='replication_user', 
MASTER_PASSWORD='password', 
MASTER_LOG_FILE='master-bin.00001', 
MASTER_LOG_POS=4;

गलत स्थान पर प्रतिकृति शुरू करने के विनाशकारी परिणाम हो सकते हैं:डेटा डबल लिखा जा सकता है या अपडेट नहीं किया जा सकता है। यह मास्टर और स्लेव नोड के बीच डेटा बहाव का कारण बनता है।

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

Oracle MySQL और MariaDB दोनों ने वैश्विक लेनदेन पहचानकर्ता (GTID) को लागू किया है। इस मुद्दे को हल करें। GTID दासों के स्वत:संरेखण की अनुमति देता है, और सर्वर स्वयं ही यह पता लगा लेता है कि सही स्थिति क्या है। हालाँकि, दोनों ने GTID को अलग तरह से लागू किया है और इसलिए असंगत हैं। यदि आपको एक से दूसरे में प्रतिकृति स्थापित करने की आवश्यकता है, तो प्रतिकृति को पारंपरिक बाइनरी लॉग पोजिशनिंग के साथ स्थापित किया जाना चाहिए। साथ ही, आपके फ़ेलओवर सॉफ़्टवेयर को GTID का उपयोग न करने के बारे में अवगत कराया जाना चाहिए।

क्रैश-सेफ स्लेव

क्रैश सेफ का मतलब है कि भले ही एक दास MySQL/OS क्रैश हो जाए, आप दास को पुनर्प्राप्त कर सकते हैं और दास पर MySQL डेटाबेस को पुनर्स्थापित किए बिना प्रतिकृति जारी रख सकते हैं। क्रैश-सुरक्षित स्लेव कार्य करने के लिए, आपको केवल InnoDB संग्रहण इंजन का उपयोग करना होगा, और 5.6 में, आपको relay_log_info_repository=TABLE और relay_log_recovery=1.

निष्कर्ष

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

यदि आप MySQL प्रतिकृति के बारे में अधिक पढ़ना चाहते हैं, तो उच्च उपलब्धता के लिए MySQL प्रतिकृति पर यह ट्यूटोरियल देखें।

डेटाबेस प्रबंधन समाधानों के बारे में अधिक अपडेट और अपने ओपन-सोर्स-आधारित डेटाबेस के लिए सर्वोत्तम प्रथाओं के लिए, ट्विटर और लिंक्डइन पर हमें फॉलो करें और हमारे न्यूज़लेटर की सदस्यता लें।