एक MySQL 5.7 मास्टर-स्लेव सेटअप में जो rpl_semi_sync_master_wait_point के लिए डिफ़ॉल्ट सेमीसिंक्रोनस प्रतिकृति सेटिंग का उपयोग करता है , स्वामी की दुर्घटना और दास की विफलता को दोषरहित माना जाता है। हालाँकि, जब दुर्घटनाग्रस्त मास्टर वापस आता है, तो आप पा सकते हैं कि उसके पास ऐसे लेन-देन हैं जो वर्तमान मास्टर में मौजूद नहीं हैं (जो पहले एक दास था)। यह व्यवहार हैरान करने वाला हो सकता है, यह देखते हुए कि सेमीसिंक्रोनस प्रतिकृति को दोषरहित माना जाता है, लेकिन यह वास्तव में MySQL में एक अपेक्षित व्यवहार है। ऐसा क्यों होता है, इसके बारे में जीन-फ्रांस्वा गैग्ने (JF) द्वारा ब्लॉग पोस्ट में विस्तार से बताया गया है।
ऐसे परिदृश्य को देखते हुए, MySQL प्रलेखन अनुशंसा करता है कि दुर्घटनाग्रस्त मास्टर को छोड़ दिया जाना चाहिए और फिर से शुरू नहीं किया जाना चाहिए। हालाँकि, इस तरह के सर्वर को हटाना महंगा और अक्षम है। इस ब्लॉग पोस्ट में, हम अर्धसिंक्रोनस प्रतिकृति सेटअप में दुर्घटनाग्रस्त MySQL मास्टर सर्वर पर लेनदेन का पता लगाने और उसे ठीक करने के लिए एक दृष्टिकोण की व्याख्या करेंगे, और इसे अपने मास्टर-स्लेव सेटअप में फिर से कैसे गुलाम बना सकते हैं।
रिकवर किए गए मास्टर पर अतिरिक्त लेन-देन का पता लगाना क्यों महत्वपूर्ण है?
रिकवर किए गए मास्टर पर अतिरिक्त लेनदेन दो तरह से प्रकट हो सकते हैं:
1. MySQL प्रतिकृति विफल हो जाती है जब पुनर्प्राप्त मास्टर को फिर से गुलाम बनाया जाता है
आमतौर पर, ऐसा तब होता है जब आपके पास एक ऑटो-इन्क्रीमेंट प्राथमिक कुंजी होती है। जब नया MySQL मास्टर ऐसी तालिका में एक पंक्ति सम्मिलित करता है, तो प्रतिकृति विफल हो जाएगी क्योंकि कुंजी पहले से दास पर मौजूद है।
एक अन्य परिदृश्य तब होता है जब आपका ऐप उस लेन-देन का पुन:प्रयास करता है जो मास्टर क्रैश के दौरान विफल हो गया था। बरामद MySQL मास्टर (जो अब एक गुलाम है) पर, यह लेनदेन वास्तव में मौजूद होगा, और फिर से, एक प्रतिकृति त्रुटि में परिणाम होगा।
आमतौर पर, MySQL प्रतिकृति त्रुटि इस तरह दिखाई देगी:
| [ERROR] स्लेव SQL for channel '':वर्कर 5 'fd1ba8f0-cbee-11e8' लेन-देन करने में विफल रहा। b27f-000d3a0df42d:5938858' मास्टर लॉग पर mysql-bin.000030, end_log_pos 10262184; क्वेरी पर 'प्राथमिक' कुंजी के लिए 'डुप्लिकेट प्रविष्टि' 5018 'त्रुटि। डिफ़ॉल्ट डेटाबेस:'परीक्षण'। क्वेरी:'परीक्षण मानों में डालें (5018,2019,'item100')', Error_code:1062 |
2. नए MySQL मास्टर और स्लेव (पुनर्प्राप्त मास्टर) के बीच डेटा में मौन असंगति
ऐसे मामलों में जहां एप्लिकेशन विफल लेनदेन का पुन:प्रयास नहीं करता है और भविष्य में कोई प्राथमिक कुंजी टकराव नहीं है, एक प्रतिकृति त्रुटि नहीं हो सकती है। परिणामस्वरूप, डेटा असंगति का पता नहीं चल पाता है।
उपरोक्त दोनों मामलों में, या तो आपके MySQL सेटअप की उच्च उपलब्धता या डेटा अखंडता प्रभावित होती है, इसलिए इस स्थिति का जल्द से जल्द पता लगाना बहुत महत्वपूर्ण है।
रिकवर किए गए MySQL मास्टर पर अतिरिक्त लेनदेन का पता कैसे लगाएं
हम यह पता लगा सकते हैं कि MySQL GTID (वैश्विक लेनदेन पहचानकर्ता) फ़ंक्शन का उपयोग करके पुनर्प्राप्त मास्टर पर कोई अतिरिक्त लेनदेन है या नहीं:
GTID_SUBSET(set1 ,सेट2 ):वैश्विक लेन-देन आईडी के दो सेट दिए गए हैं set1 और सेट2 , सत्य लौटाता है यदि set1 . में सभी GTID सेट2 . में भी हैं . अन्यथा झूठी वापसी करता है।
आइए इसे समझने के लिए एक उदाहरण का उपयोग करते हैं।
- GTID पुनर्प्राप्त मास्टर पर सेट है जिसका UUID है:'54a63bc3-d01d-11e7-bf52-000d3af93e52 ' है:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
- नए मास्टर का GTID सेट जिसका UUID है:'57956099-d01d-11e7-80bc-000d3af97c09 है:
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'
अब, अगर हम GTID_SUBSET फ़ंक्शन को GTID_SUBSET(पुनर्प्राप्त मास्टर का GTID सेट, नए मास्टर का GTID सेट) कहते हैं , वापसी मूल्य तभी सही होगा जब पुनर्प्राप्त मास्टर के पास कोई अतिरिक्त लेनदेन न हो। ऊपर दिए गए हमारे उदाहरण में, चूंकि रिकवर किए गए मास्टर के पास 9691 से 9700 तक अतिरिक्त लेनदेन हैं, इसलिए उपरोक्त क्वेरी का परिणाम गलत है।
अर्धसिंक्रोनस प्रतिकृति सेटअप में एक दुर्घटनाग्रस्त #MySQL मास्टर सर्वर को फिर से स्लेव करनाट्वीट करने के लिए क्लिक करेंरिकवर किए गए MySQL मास्टर को फिर से स्लेव कैसे करें, जिसमें अतिरिक्त ट्रांजैक्शन हैं
उपरोक्त चरण के आधार पर, यह जानना संभव है कि क्या पुनर्प्राप्त मास्टर के पास अतिरिक्त लेन-देन हैं, और ये लेन-देन GTID फ़ंक्शन का उपयोग कर रहे हैं:GTID_SUBTRACT(GTID का सेट पुनर्प्राप्त मास्टर, नए मास्टर का GTID सेट)।
इन अतिरिक्त लेनदेन को बाइनरी लॉग से निकालना और उन्हें सहेजना भी संभव है। आपकी व्यावसायिक टीम के लिए बाद में इन लेन-देनों की समीक्षा करना उपयोगी हो सकता है ताकि यह सुनिश्चित हो सके कि हम अनजाने में कोई महत्वपूर्ण व्यावसायिक जानकारी नहीं खो रहे हैं, भले ही वह प्रतिबद्ध नहीं थी। एक बार यह हो जाने के बाद, हमें इन अतिरिक्त लेन-देन से छुटकारा पाने का एक तरीका चाहिए ताकि बरामद मास्टर को बिना किसी समस्या के फिर से गुलाम बनाया जा सके।
ऐसा करने का सबसे आसान तरीका है कि वर्तमान मास्टर पर एक बैकअप स्नैपशॉट लें और डेटा को अपने वर्तमान दास पर पुनर्स्थापित करें। याद रखें कि आपको इस सर्वर के UUID को पहले की तरह बनाए रखना होगा। आपके द्वारा डेटा को पुनर्स्थापित करने के बाद, सर्वर को फिर से स्लेव किया जा सकता है, और यह पुनर्स्थापित स्नैपशॉट के बिंदु से प्रतिकृति शुरू कर देगा। जल्द ही आपके पास एक स्वस्थ दास फिर से दौड़ेगा!
यदि आपको उन्हें मैन्युअल रूप से निष्पादित करना है तो उपरोक्त चरण बहुत कठिन हैं, लेकिन स्केलग्रिड की पूरी तरह से प्रबंधित MySQL होस्टिंग सेवा बिना किसी हस्तक्षेप के आपके लिए पूरी प्रक्रिया को स्वचालित कर सकती है। यहां बताया गया है कि यह कैसे काम करता है:
यदि आपका वर्तमान मास्टर क्रैश हो जाता है, तो ScaleGrid विफलता प्रक्रिया को स्वचालित करता है और एक उपयुक्त दास को नए मास्टर के रूप में बढ़ावा देता है। पुराना मास्टर तब पुनर्प्राप्त किया जाता है, और हम स्वचालित रूप से पता लगाते हैं कि उस पर अतिरिक्त लेनदेन हैं या नहीं। यदि कोई पाया जाता है, तो MySQL परिनियोजन को खराब स्थिति में डाल दिया जाता है, और हम आपकी समीक्षा के लिए अतिरिक्त लेनदेन को निकालने और सहेजने के लिए स्वचालित टूल का उपयोग करते हैं। हमारी सहायता टीम तब पुराने मास्टर को एक अच्छी स्थिति में पुनर्स्थापित कर सकती है, और इसे आपके मास्टर-स्लेव सेटअप में वापस ला सकती है ताकि आपके पास एक स्वस्थ परिनियोजन हो!
इसे आजमाना चाहते हैं? स्केलग्रिड पर सभी MySQL डेटाबेस प्रबंधन क्षमताओं को एक्सप्लोर करने के लिए 30-दिन का निःशुल्क परीक्षण प्रारंभ करें।
