MySQL प्रतिकृति में बचने के लिए शीर्ष गलतियाँ

MySQL में प्रतिकृति स्थापित करना आसान है, लेकिन इसे उत्पादन में प्रबंधित करना कभी आसान काम नहीं रहा है। नई GTID ऑटो-पोजिशनिंग के साथ भी, यदि आप नहीं जानते कि आप क्या कर रहे हैं, तब भी यह गलत हो सकता है। प्रतिकृति स्थापित करने के बाद, सभी प्रकार की चीजें गलत हो सकती हैं। गलतियाँ आसानी से की जा सकती हैं और आपके डेटा का विनाशकारी अंत हो सकता है।

यह पोस्ट MySQL प्रतिकृति के साथ की गई कुछ सबसे सामान्य गलतियों पर प्रकाश डालेगी, और आप उन्हें कैसे रोक सकते हैं।

प्रतिकृति सेट करना

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

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

mysqldump को एक लेनदेन के रूप में डंप की तरह अधिक विश्वसनीय बनाने के लिए आप कुछ बदलाव कर सकते हैं, और रूटीन और ट्रिगर्स को शामिल करना न भूलें:

mysqldump -uuser -ppass --single-transaction --routines --triggers --all-databases > dumpfile.sql

एक अच्छा अभ्यास यह जांचना है कि क्या आपका दास नोड 100% समान है, प्रतिकृति स्थापित करने के बाद पीटी-टेबल-चेकसम का उपयोग कर रहा है:

pt-table-checksum --replicate=test.checksums --ignore-databases mysql h=localhost,u=user,p=pass

यह उपकरण मास्टर पर प्रत्येक तालिका के लिए एक चेकसम की गणना करेगा, दास को कमांड को दोहराएगा और फिर दास नोड समान चेकसम ऑपरेशन करेगा। यदि कोई भी तालिका समान नहीं है, तो यह चेकसम तालिका में स्पष्ट रूप से दिखाई देनी चाहिए।

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

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

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

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

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

गोलाकार प्रतिकृति

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

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

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

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

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

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

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

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

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

स्कीमा परिवर्तन

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

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

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

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

मेमोरी टेबल और प्रतिकृति

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

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

केवल पढ़ने योग्य चर को सही पर सेट करना

जैसा कि हमने पहले बताया, दास नोड्स में समान डेटा नहीं होने से प्रतिकृति टूट सकती है। अक्सर यह किसी चीज़ (या किसी) द्वारा दास नोड पर डेटा को बदलने के कारण होता है, लेकिन मास्टर नोड पर नहीं। एक बार जब मास्टर नोड का डेटा बदल जाता है, तो इसे दास को दोहराया जाएगा जहां यह परिवर्तन लागू नहीं कर सकता है और इससे प्रतिकृति टूट जाती है।

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

यह अभी भी रूट उपयोगकर्ता को गुलाम नोड पर एक गलत CRUD क्वेरी निष्पादित करने के लिए छोड़ देता है। ऐसा होने से रोकने के लिए, MySQL 5.7.8 के बाद से एक super_read_only वेरिएबल है जो रूट उपयोगकर्ता को डेटा अपडेट करने से भी रोकता है।

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.0001', MASTER_LOG_POS=  04;

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

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

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

निष्कर्ष

हम आशा करते हैं कि आपको परेशानी से बचने के लिए पर्याप्त सुझाव दिए होंगे। MySQL के विशेषज्ञों द्वारा ये सभी सामान्य प्रथाएं हैं। उन्हें इसे कठिन तरीके से सीखना था और इन युक्तियों के साथ हम सुनिश्चित करते हैं कि आपको ऐसा नहीं करना है।

हमारे पास कुछ अतिरिक्त श्वेत पत्र हैं जो उपयोगी हो सकते हैं यदि आप MySQL प्रतिकृति के बारे में अधिक पढ़ना चाहते हैं।