VPN कटने के बाद MySQL प्रतिकृति: पहले दोनों चरण पढ़ें

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

दो चरण, दो अलग उत्तर

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

रिसीवर का ठीक होना बताता है कि मार्ग चालू है। यह नहीं बताता कि एप्लायर कितना पीछे है, या डिस्कनेक्ट रहते हुए उसे कोई त्रुटि मिली या नहीं।

सही कथन से चैनल पढ़ें

MySQL 8.4 में, SHOW REPLICA STATUS प्रत्येक कॉन्फ़िगर किए गए चैनल के लिए एक पंक्ति लौटाता है, इसलिए सूची की पहली पंक्ति के बजाय उस चैनल की पंक्ति पढ़ें जिसका आपका आशय है। Replica_IO_Running जुड़े हुए रिसीवर को जुड़ रहे या रुके हुए रिसीवर से अलग करता है, और Replica_SQL_Running एप्लायर का वर्णन करता है। उनके साथ त्रुटि वाले कॉलम भी पढ़ें, क्योंकि फिर से जुड़कर तुरंत विफल होने वाला रिसीवर ऐसा संदेश छोड़ता है जो कोई स्थिति फ़्लैग नहीं दिखाएगा। पुराने संस्करण अलग कॉलम नाम इस्तेमाल करते हैं, इसलिए केवल कमांड के नाम बदलकर पुरानी विधि का अनुवाद न करें।

स्रोत की पहचान और कॉन्फ़िगर किए गए फ़िल्टर भी जाँचें। गलत स्रोत की ओर इंगित, या आपकी सोच से अधिक संकीर्ण रूप से फ़िल्टर की गई प्रतिकृति स्वस्थ होने की सूचना देती है जबकि वह आपकी अपेक्षा से भिन्न कुछ प्रतिकृत कर रही होती है।

शून्य अंतराल का आँकड़ा क्यों झूठ बोल सकता है

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

इसके बजाय निष्पादित लेन-देन की तुलना स्रोत के पास उपलब्ध से करें। वह तुलना रुके हुए रिसीवर में भी टिकी रहती है।

वास्तविक पुनर्प्राप्ति अवधि अवधारण तय करता है

पकड़ पाने के लिए ज़रूरी है कि स्रोत प्रतिकृति को चाहिए वाले लेन-देन अभी भी रखे। उनके हटते ही प्रतिकृति उन्हें नहीं ला सकती, और कितनी भी पुनःकनेक्ट उसे नहीं बदलती।

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

पकड़ की पुष्टि करें, किसी संकेतक का रंग नहीं

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

पुष्टि करें कि एप्लायर स्रोत की वर्तमान स्थिति तक पहुँच गया है, केवल पुराने बैकलॉग के अंत तक नहीं। जाँचें कि एप्लायर में कोई त्रुटि प्रतीक्षा में नहीं है, क्योंकि एक विफल घटना प्रगति रोक देती है जबकि रिसीवर जुड़े होने की सूचना देता रहता है। फिर साक्ष्य दर्ज करें: चैनल का नाम, दोनों चरणों की स्थिति, निष्पादित स्थिति और समय। हरा संकेतक एक दावा है; स्थिति एक तथ्य है।