VPN तुटल्यानंतर MySQL प्रतिकृती: आधी दोन्ही टप्पे वाचा

VPN पडल्यावर प्रतिकृतीचे निरीक्षण लाल होते, आणि पहिली प्रवृत्ती स्थान रीसेट करण्याची असते। हीच प्रवृत्ती नेटवर्क अडथळ्याचे डेटा समस्येत रूपांतर करते। पडलेला मार्ग प्रतिकृतीने काय घेतले किंवा काय लागू केले याबद्दल काहीही सांगत नाही, आणि ते दोन स्थितींचे दोन टप्पे आहेत। काहीही बदलण्यापूर्वी ते वेगळे वाचा।

दोन टप्पे, दोन वेगळी उत्तरे

नेहमीची असिंक्रोनस प्रतिकृती दोन कामे करते। प्राप्तकर्ता स्रोताशी जोडतो, घटना ओढतो आणि त्या स्थानिक पातळीवर रिले लॉगमध्ये लिहितो। लागूकर्ता तो लॉग वाचतो आणि घटना प्रतिकृतीवर चालवतो। मार्ग तुटल्यावर प्राप्तकर्ता लगेच थांबतो, तर लागूकर्ता डिस्कवर आधीच असलेला साठा प्रक्रिया करत राहतो। म्हणून एक अडथळा दोन वेगळे प्रश्न निर्माण करतो: कनेक्शन परत आले का, आणि साठलेले काम लागू झाले का? त्यांना एकच प्रश्न मानल्यास दोन स्थिती मिसळून भ्रमित करणारे उत्तर बनते।

प्राप्तकर्त्याची पुनर्प्राप्ती मार्ग चालू असल्याचे सांगते। लागूकर्ता किती मागे आहे, किंवा डिस्कनेक्ट असताना त्याला त्रुटी आढळली का, हे ते सांगत नाही।

योग्य विधानाने चॅनेल वाचा

MySQL 8.4 मध्ये, SHOW REPLICA STATUS प्रत्येक संरचित चॅनेलसाठी एक ओळ परत करते, म्हणून यादीतील पहिल्या ओळीऐवजी तुम्हाला अभिप्रेत असलेल्या चॅनेलची ओळ वाचा। Replica_IO_Running जोडलेल्या प्राप्तकर्त्याला जोडत असलेल्या किंवा थांबलेल्या प्राप्तकर्त्यापासून वेगळे करते, आणि Replica_SQL_Running लागूकर्त्याचे वर्णन करते। त्यांच्या शेजारील त्रुटी स्तंभही वाचा, कारण पुन्हा जोडून लगेच अपयशी होणारा प्राप्तकर्ता असा संदेश सोडतो जो कोणताही स्थिती ध्वज दाखवणार नाही। जुन्या आवृत्त्या वेगळी स्तंभ नावे वापरतात, म्हणून केवळ आदेशांची नावे बदलून जुनी पद्धत भाषांतरित करू नका।

स्रोताची ओळख आणि संरचित फिल्टरही तपासा। चुकीच्या स्रोताकडे निर्देशित, किंवा तुम्ही विचार करता त्यापेक्षा अरुंद फिल्टर केलेली प्रतिकृती आरोग्य असल्याचे नोंदवते, पण तुमच्या अपेक्षेपेक्षा वेगळे काही प्रतिकृत करत असते।

शून्य विलंबाचा आकडा का खोटे बोलू शकतो

विलंबाचे मूल्य शेवटच्या लागू झालेल्या घटनेची वेळमुद्रा सध्याच्या वेळेशी तुलना करते। प्राप्तकर्ता एक तास थांबलेला असल्यास, लागूकर्ता साठा संपवून मिळालेल्याच्या शेवटापर्यंत पोहोचू शकतो, आणि तेव्हा प्रतिकृती स्रोताच्या एक तास मागे असली तरी आकडा शून्यावर येतो। हे मापन लागूकर्त्याची रांग मोजते, प्रतिकृतीची अद्ययावतता नाही।

त्याऐवजी चालवलेल्या व्यवहारांची स्रोताकडे उपलब्ध असलेल्यांशी तुलना करा। ती तुलना थांबलेल्या प्राप्तकर्त्यातही टिकते।

खऱ्या पुनर्प्राप्तीची खिडकी धारणा ठरवते

पकडण्यासाठी स्रोताने प्रतिकृतीला आवश्यक असलेले व्यवहार अजून ठेवले पाहिजेत। ते साफ झाल्यावर प्रतिकृती ते आणू शकत नाही, आणि कितीही पुन्हा जोडले तरी ते बदलत नाही।

GTID स्वयं-स्थितीसह अपयश स्पष्ट आहे: प्रतिकृती स्रोताकडे आता नसलेला इतिहास मागते आणि पुढे जाण्यास नकार देते। तेव्हा पर्याय म्हणजे गमावलेल्या घटना अजून असलेल्या स्रोताकडून मिळवणे, किंवा बॅकअपमधून पुन्हा बांधून तिला पकडू देणे। अंतर सोडून देणे हे पकडणे नाही, आणि ते डेटा गुपचूप अपूर्ण असलेली प्रतिकृती सोडते। अपेक्षित अडथळ्याचा कालावधी स्रोतावरील बायनरी लॉग धारणा आणि बदलाचा दर यांच्याशी तुलना करून खिडकीचे नियोजन करा, कारण तेच तीन आकडे अडथळा अजिबात पुनर्प्राप्त करण्यायोग्य आहे का हे ठरवतात।

निर्देशकाचा रंग नाही, पकडलेले ते तपासा

मार्ग पुनर्संचयित करा, त्यात नाव निराकरण आणि वाहतूक सुरक्षा समाविष्ट आहे, नंतर विद्यमान चॅनेल स्वतःच्या धोरणानुसार पुन्हा जोडते का ते पाहा। हस्तक्षेप करण्यापूर्वी त्याला ठराविक अंतराल द्या, आणि त्या अंतरालाच्या दोन्ही टोकांवर प्राप्ती व लागूकरणाची प्रगती नोंदवा। पुन्हा सुरू होणारे चॅनेल आणि अद्ययावत चॅनेल वेगवेगळे निष्कर्ष आहेत।

लागूकर्ता स्रोताच्या सध्याच्या स्थानापर्यंत पोहोचला आहे याची खात्री करा, केवळ जुन्या साठ्याच्या शेवटापर्यंत नाही। लागूकर्त्यात कोणतीही त्रुटी वाट पाहत नाही हे तपासा, कारण एक अपयशी घटना प्रगती थांबवते, तर प्राप्तकर्ता जोडलेले असल्याचे नोंदवत राहतो। नंतर पुरावे नोंदवा: चॅनेलचे नाव, दोन्ही टप्प्यांची स्थिती, चालवलेले स्थान आणि वेळ। हिरवा निर्देशक एक दावा आहे; स्थान एक वस्तुस्थिती आहे।