VPN काटिएपछि MySQL प्रतिलिपि: पहिले दुवै चरण पढ्नुहोस्

VPN खस्दा प्रतिलिपि निगरानी रातो हुन्छ, र पहिलो प्रवृत्ति स्थिति रिसेट गर्ने हुन्छ। यही प्रवृत्तिले सञ्जाल अवरोधलाई डेटा समस्यामा बदल्छ। खसेको बाटोले प्रतिलिपिले के प्राप्त गर्यो वा के लागू गर्यो भन्नेबारे केही भन्दैन, र ती दुई अवस्था भएका दुई चरण हुन्। केही बदल्नुअघि तिनीहरूलाई छुट्टाछुट्टै पढ्नुहोस्।

दुई चरण, दुई छुट्टै उत्तर

सामान्य असमकालिक प्रतिलिपिले दुई काम गर्छ। प्राप्तकर्ता स्रोतसँग जोडिन्छ, घटनाहरू तान्छ र तिनीहरूलाई स्थानीय रूपमा रिले लगमा लेख्छ। लागूकर्ताले त्यो लग पढ्छ र घटनाहरू प्रतिलिपिमा कार्यान्वयन गर्छ। बाटो टुट्दा प्राप्तकर्ता तुरुन्तै रोकिन्छ, जबकि लागूकर्ता डिस्कमा पहिले नै रहेको बाँकी काम गर्न जारी राख्छ। त्यसैले एउटा अवरोधले दुई फरक प्रश्न उत्पन्न गर्छ: जडान फर्कियो कि, र जम्मा भएको काम लागू भयो कि? तिनीहरूलाई एउटै प्रश्न मान्दा दुई अवस्था मिसिएर भ्रमित उत्तर बन्छ।

प्राप्तकर्ताको पुनःप्राप्तिले बाटो चालु छ भन्छ। लागूकर्ता कति पछि छ, वा विच्छेद हुँदा त्रुटि भेट्यो कि भन्ने कुरा यसले भन्दैन।

सही कथनले च्यानल पढ्नुहोस्

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

स्रोतको पहिचान र कन्फिगर गरिएका फिल्टरहरू पनि जाँच्नुहोस्। गलत स्रोततर्फ देखाइएको, वा तपाईं सोच्नुभएभन्दा साँघुरो फिल्टर गरिएको प्रतिलिपि स्वस्थ भएको रिपोर्ट गर्छ, जबकि तपाईंको अपेक्षाभन्दा फरक कुरा प्रतिलिपि गरिरहेको हुन्छ।

शून्य ढिलाइको अङ्क किन झुट बोल्न सक्छ

ढिलाइको मानले अन्तिम लागू गरिएको घटनाको समय-छापलाई हालको समयसँग तुलना गर्छ। प्राप्तकर्ता एक घण्टा रोकिएको हुँदा, लागूकर्ताले बाँकी सकाएर प्राप्त गरेको अन्त्यसम्म पुग्न सक्छ, र त्यसपछि प्रतिलिपि स्रोतभन्दा एक घण्टा पछि हुँदा पनि अङ्क शून्यमा झर्छ। यो मापनले लागूकर्ताको कतार माप्छ, प्रतिलिपिको अद्यावधिकता होइन।

बरु कार्यान्वित कारोबारहरूलाई स्रोतसँग उपलब्ध भएकोसँग तुलना गर्नुहोस्। त्यो तुलनाले रोकिएको प्राप्तकर्तालाई पनि सहन्छ।

वास्तविक पुनःप्राप्ति विन्डो अवधारणले निर्धारण गर्छ

भेट्नका लागि स्रोतले प्रतिलिपिलाई आवश्यक कारोबारहरू अझै राख्नुपर्छ। ती हटाइएपछि प्रतिलिपिले तिनीहरू ल्याउन सक्दैन, र कति पटक पुनःजडान गरे पनि त्यो बदलिँदैन।

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

सूचकको रङ होइन, भेटिएको कुरा प्रमाणित गर्नुहोस्

बाटो पुनर्स्थापित गर्नुहोस्, जसमा नाम समाधान र यातायात सुरक्षा समावेश छ, त्यसपछि विद्यमान च्यानलले आफ्नै नीतिअनुसार पुनः जोडिन्छ कि हेर्नुहोस्। हस्तक्षेप गर्नुअघि यसलाई निश्चित अन्तराल दिनुहोस्, र त्यो अन्तरालका दुवै छेउमा प्राप्ति र लागूको प्रगति अभिलेख गर्नुहोस्। पुनः सुरु हुने च्यानल र अद्यावधिक च्यानल फरक निष्कर्ष हुन्।

लागूकर्ता स्रोतको हालको स्थानमा पुगेको पुष्टि गर्नुहोस्, केवल पुरानो बाँकीको अन्त्यमा मात्र होइन। लागूकर्तामा कुनै त्रुटि पर्खिरहेको छैन भनी जाँच्नुहोस्, किनकि एउटा असफल घटनाले प्रगति रोक्छ, जबकि प्राप्तकर्ताले जोडिएको भनी रिपोर्ट गरिरहन्छ। त्यसपछि प्रमाण अभिलेख गर्नुहोस्: च्यानलको नाम, दुवै चरणको स्थिति, कार्यान्वित स्थान र समय। हरियो सूचक एउटा दाबी हो; स्थान एउटा तथ्य हो।