🧙🏽 😔 🧖🏿 टारेंटूल प्रतिकृति: कॉन्फ़िगरेशन और उपयोग ❗️ 🤴🏿 🎠

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

प्रतिकृति के बारे में

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

हम प्रतिकृति को दो मुख्य तरीकों से वर्गीकृत करते हैं:

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

टारेंटूल में प्रतिकृति कैसे काम करती है?

टारेंटूल में प्रतिकृति में कई विशेषताएं हैं:

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

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

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

यदि टारनटूल में प्रतिकृति यूनिडायरेक्शनल मास्टर-स्लेव है, तो मास्टर-मास्टर कैसे बनाया जाए? बहुत सरल: एक और प्रतिकृति चैनल बनाएं लेकिन दूसरी दिशा में। आपको यह समझने की आवश्यकता है कि टारेंटूल में, मास्टर-मास्टर प्रतिकृति सिर्फ दो डेटा धाराओं का एक संयोजन है जो एक दूसरे से स्वतंत्र हैं।

उसी सिद्धांत का उपयोग करते हुए, हम एक तीसरे मास्टर को कनेक्ट कर सकते हैं, और परिणामस्वरूप एक पूर्ण जाल नेटवर्क का निर्माण करते हैं जिसमें प्रत्येक प्रतिकृति अन्य सभी प्रतिकृतियों के लिए एक मास्टर और दास होती है।

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

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

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

क्लस्टर संचालन लेबलिंग

सवाल यह उठता है: यदि सभी क्लस्टर सदस्यों के बीच संचालन सम्‍मिलित है और प्रत्‍येक प्रतिकृति में कई बार आते हैं, तो हम कैसे समझते हैं कि किस ऑपरेशन को करने की आवश्‍यकता है और कौन सा नहीं? इसके लिए एक फ़िल्टरिंग तंत्र की आवश्यकता होती है। लॉग से पढ़े गए प्रत्येक ऑपरेशन को दो विशेषताएँ दी गई हैं:

सर्वर की पहचानकर्ता जिस पर यह ऑपरेशन शुरू किया गया था।
सर्वर पर ऑपरेशन की अनुक्रम संख्या, lsn, जो इसका सर्जक है। प्रत्येक सर्वर, जब एक ऑपरेशन करते हैं, तो प्रत्येक प्राप्त लॉग लाइन को एक बढ़ती हुई संख्या प्रदान करता है: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ... इस प्रकार, अगर हम जानते हैं कि एक निश्चित पहचानकर्ता वाले सर्वर के लिए, हमने आवेदन किया था lsn 10, फिर अन्य प्रतिकृति चैनलों के माध्यम से आए lsn 9, 8, 7, 10 के साथ संचालन आवश्यक नहीं है। इसके बजाय, हम निम्नलिखित लागू करते हैं: 11, 12, और इसी तरह।

प्रतिकृति स्थिति

और टारनटूल उन ऑपरेशनों के बारे में जानकारी कैसे संग्रहीत करता है जो उसने पहले ही लागू किए हैं? ऐसा करने के लिए, एक Vclock घड़ी है - यह क्लस्टर में प्रत्येक नोड पर लागू अंतिम lsn का वेक्टर है।

[lsn ₁ , lsn ₂ , lsn _n ]

जहां lsn _i , पहचानकर्ता के साथ सर्वर से अंतिम ज्ञात ऑपरेशन की संख्या है।

Vlock को इस प्रतिकृति के लिए ज्ञात संपूर्ण क्लस्टर स्थिति का एक निश्चित स्नैपशॉट भी कहा जा सकता है। जो ऑपरेशन का सर्वर आईडी आया है, उसे जानने के बाद, हम स्थानीय वीक्लॉक के घटक को अलग करते हैं जिसकी हमें आवश्यकता है, प्राप्त किए गए lsn की तुलना lsn ऑपरेशन से करें, और तय करें कि इस ऑपरेशन का उपयोग करना है या नहीं। नतीजतन, एक विशिष्ट मास्टर द्वारा शुरू किए गए संचालन को क्रमिक रूप से भेजा और लागू किया जाएगा। इसी समय, विभिन्न मास्टर्स पर बनाई गई वर्कफ़्लोज़ को अतुल्यकालिक प्रतिकृति के कारण एक दूसरे के साथ मिलाया जा सकता है।

क्लस्टर निर्माण

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

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

एक क्लस्टर में एक प्रतिकृति रजिस्टर करें

क्लस्टर की संरचना के बारे में राज्य को संग्रहीत करने के लिए, एक विशेष स्थान का उपयोग किया जाता है - क्लस्टर। इसमें क्लस्टर में सर्वर पहचानकर्ता, उनके सीरियल नंबर और अद्वितीय पहचानकर्ता शामिल हैं।

[1, 'c35b285c-c5b1-4bbe-83b1-b825eb594aa4']
[2, '37b12cb7-d324-4d75-b428-cde92c18e708']
[3, 'b72b1aa6-42a0-4d73-a611-900e44cdd465']

पहचानकर्ताओं को क्रम में जाने की आवश्यकता नहीं है, क्योंकि नोड्स को गिराया और जोड़ा जा सकता है।

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

यहाँ एक गलत और सही JOIN का उदाहरण दिया गया है:

हमारे पास दो स्वामी और दो प्रतिकृतियां हैं जो कनेक्ट करना चाहते हैं। वे अलग-अलग मास्टर्स पर जॉइन करते हैं। मान लीजिए कि प्रतिकृतियों को समान पहचानकर्ता मिलते हैं। फिर स्वामी और उनके लॉग को दोहराने के लिए प्रबंधन करने वालों के बीच प्रतिकृति अलग हो जाएगी, क्लस्टर अलग हो जाएगा।

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

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

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

मान लीजिए कि हमसे गलती हुई है, या व्यवस्थापक कॉन्फ़िगरेशन को ठीक करना भूल गया है, या अन्सिबल टूट गया है, और क्लस्टर अभी भी अलग हो गया है। इसकी क्या गवाही दे सकते हैं? सबसे पहले, प्लग करने योग्य प्रतिकृतियां अपने स्थानीय स्नैपशॉट बनाने में सक्षम नहीं होंगी: प्रतिकृतियां शुरू नहीं होती हैं और त्रुटियों की रिपोर्ट करती हैं। दूसरे, लॉग में स्वामी पर, हम अंतरिक्ष क्लस्टर में संघर्षों से संबंधित त्रुटियों को देखेंगे।

हम इस स्थिति को कैसे हल करते हैं? यह सरल है:

सबसे पहले, हमें उस कॉन्फ़िगरेशन को मान्य करना होगा जिसे हम कनेक्टिंग प्रतिकृतियों के लिए सेट करते हैं, क्योंकि अगर हम इसे ठीक नहीं करते हैं, तो बाकी सब बेकार हो जाएगा।
उसके बाद, हम क्लस्टर में संघर्षों को दूर करते हैं और एक तस्वीर लेते हैं।

अब आप प्रतिकृतियों को फिर से शुरू करने की कोशिश कर सकते हैं।

संघर्ष का संकल्प

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

जॉय निष्पादित करने के बाद एक उदाहरण क्लस्टर है:

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

एक छोटा सा उदाहरण। मान लीजिए कि vclock = {0,0} के साथ हमारे दो स्वामी हैं। और दोनों दो ऑपरेशन करेंगे, जिन्हें op1,1, op1,2, op2,1, op2,2 के रूप में नामित किया गया है। यह दूसरी बार टुकड़ा है जब प्रत्येक स्वामी ने एक स्थानीय ऑपरेशन किया:

ग्रीन संबंधित vclock घटक में बदलाव को इंगित करता है। सबसे पहले, दोनों स्वामी अपने vclock को बदलते हैं, और फिर दूसरा मास्टर एक और स्थानीय ऑपरेशन करता है और फिर से vclock बढ़ाता है। पहला मास्टर दूसरे मास्टर से प्रतिकृति ऑपरेशन प्राप्त करता है, यह पहले क्लस्टर नोड के vlock में लाल नंबर 1 द्वारा इंगित किया गया है।

फिर दूसरा मास्टर पहले से ऑपरेशन प्राप्त करता है, और पहला - दूसरे से दूसरा ऑपरेशन। और अंत में, पहला मास्टर अपना अंतिम ऑपरेशन करता है, और दूसरा मास्टर इसे प्राप्त करता है।

शून्य समय की मात्रा में Vclock हमारे पास समान है - {0,0}। समय की अंतिम मात्रा पर, हमारे पास एक ही vclock {2,2} भी है, ऐसा लगता है कि डेटा समान होना चाहिए। लेकिन प्रत्येक मास्टर पर किए गए संचालन का क्रम अलग है। और अगर यह एक ही कुंजी के लिए विभिन्न मूल्यों के साथ एक प्रतिक्रिया ऑपरेशन है? फिर, अंत में एक ही vclock के बावजूद, हम दोनों प्रतिकृतियों पर डेटा के विभिन्न संस्करण प्राप्त करेंगे।

हम इस स्थिति को हल करने में भी सक्षम हैं।

रिकॉर्ड साझा करना । सबसे पहले, हम बेतरतीब ढंग से चयनित प्रतिकृतियों पर नहीं, बल्कि किसी भी तरह से उन पर शार्द कर सकते हैं। उन्होंने विभिन्न मास्टर्स में लेखन कार्यों को तोड़ दिया और अंततः एक सुसंगतता प्रणाली प्राप्त की। उदाहरण के लिए, चाबियाँ एक मास्टर पर 1 से 10 और दूसरे पर 11 से 20 तक बदल गई हैं - नोड्स अपने लॉग का आदान-प्रदान करेंगे और ठीक उसी डेटा को प्राप्त करेंगे।

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

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

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

तुल्यकालन

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

ACK क्या है? जब दास को डेल्टा प्राप्त होता है, जिसे मास्टर lsn और उसके पहचानकर्ता के साथ चिह्नित किया जाता है, तो प्रतिक्रिया में यह एक विशेष ACK पैकेट भेजता है, जिसमें यह इस ऑपरेशन को लागू करने के बाद अपने स्थानीय vclock को पैक करता है। आइए देखें कि यह कैसे काम कर सकता है।

हमारे पास एक मास्टर है जिसने स्वयं में 4 ऑपरेशन किए। मान लीजिए कि किसी समय दास दासी को पहली तीन पंक्तियाँ मिलीं और इसका vclock बढ़कर {3.0} हो गया।

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

और अंत में, दास एक चौथे एसीके पैकेट के साथ प्रतिक्रिया करता है। उसके बाद, मास्टर जानता है कि दास इसके साथ सिंक्रनाइज़ है।

इस तंत्र का उपयोग एप्लिकेशन कोड में किया जा सकता है। जब आप एक ऑपरेशन करते हैं, तो आप तुरंत उपयोगकर्ता को स्वीकार नहीं करते हैं, लेकिन पहले एक विशेष फ़ंक्शन को कॉल करते हैं। यह उस मास्टर के लिए ज्ञात lsn गुलाम का इंतजार करता है, जब कमिट पूरी होने के समय आपके मास्टर के lsn के बराबर होता है। इसलिए आपको पूर्ण सिंक्रनाइज़ेशन के लिए प्रतीक्षा करने की आवश्यकता नहीं है, बस उल्लिखित क्षण की प्रतीक्षा करें।

मान लीजिए कि हमारी पहली कॉल में तीन लाइनें बदल गई हैं, और दूसरी कॉल एक बदल गई है। पहली कॉल के बाद, आप यह सुनिश्चित करना चाहते हैं कि डेटा सिंक्रनाइज़ है। ऊपर दिखाए गए राज्य का मतलब पहले से ही है कि पहली कॉल कम से कम एक दास पर सिंक्रनाइज़ की गई थी।

इस बारे में जानकारी के लिए वास्तव में कहां देखें, हम अगले भाग में विचार करेंगे।

निगरानी

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

बुनियादी निगरानी के लिए, टारनटूल के पास एक बॉक्स.ऑफ़ संस्था है। यह कंसोल में कॉल करने के लायक है, क्योंकि आप दिलचस्प डेटा देखेंगे।

 id: 1 uuid: c35b285c-c5b1-4bbe-83b1-b825eb594aa4 lsn : 5 vclock : {2: 1, 1: 5} replication : 1: id: 1 uuid : c35b285c -c5b1 -4 bbe -83b1 - b825eb594aa4 lsn : 5 2: id: 2 uuid : 37 b12cb7 -d324 -4 d75 -b428 - cde92c18e708 lsn : 1 upstream : status : follow idle : 0.30358312401222 peer : lag: 3.6001205444336 e -05 downstream : vclock : {2: 1, 1: 5}

सबसे महत्वपूर्ण मीट्रिक आईडी id । इस मामले में, 1 का अर्थ है कि इस मास्टर के एलएसएन को सभी vclock में पहले स्थान पर संग्रहीत किया जाएगा। एक बहुत ही उपयोगी चीज। यदि आपका JOIN के साथ कोई विवाद है, तो आप केवल विशिष्ट पहचानकर्ताओं द्वारा एक मास्टर को दूसरे से अलग कर सकते हैं। इसके अलावा, स्थानीय मात्रा में ऐसी मात्रा शामिल है जैसे कि एलएसएन। यह अंतिम पंक्ति की संख्या है जिसे इस मास्टर ने निष्पादित किया और अपने लॉग को लिखा। हमारे उदाहरण में, पहले मास्टर ने पांच ऑपरेशन किए। Vclock संचालन की स्थिति है जिसे वह जानता है कि उसने खुद पर लागू किया था। और अंत में, मास्टर नंबर 2 के लिए, उन्होंने अपने प्रतिकृति कार्यों में से एक का प्रदर्शन किया।

स्थानीय राज्य के संकेतकों के बाद, आप देख सकते हैं कि यह उदाहरण क्लस्टर प्रतिकृति की स्थिति के बारे में क्या जानता है, इसके लिए एक replication अनुभाग है। यह उदाहरण सहित ज्ञात सभी क्लस्टर नोड्स को सूचीबद्ध करता है। पहले नोड में पहचानकर्ता 1 है, आईडी वर्तमान उदाहरण से मेल खाती है। दूसरे नोड में पहचानकर्ता 2 है, इसका lsn 1 उस lsn से मेल खाता है जो vclock को लिखा गया है। इस मामले में, हम मास्टर-मास्टर प्रतिकृति पर विचार करते हैं, जब मास्टर नंबर 1 क्लस्टर के दूसरे नोड और इसके दास के लिए दोनों मास्टर है, अर्थात यह इसका अनुसरण करता है।

upstream का सार। status follow विशेषता का मतलब है कि मास्टर 1 मास्टर के बाद 2 है। आइडल वह समय है जो इस मास्टर के साथ अंतिम बातचीत के बाद से स्थानीय रूप से बीत चुका है। हम लगातार एक स्ट्रीम नहीं भेजते हैं, मास्टर केवल एक डेल्टा भेजता है जब उस पर परिवर्तन होते हैं। जब हम किसी प्रकार का ACK भेजते हैं, तो हम संवाद भी करते हैं। जाहिर है, अगर निष्क्रिय बड़ा (सेकंड, मिनट, घंटे) हो जाता है, तो कुछ गलत है।
lag गुण। हमने अंतराल के बारे में बात की। Lsn और server id अलावा server id लॉग में प्रत्येक ऑपरेशन को टाइमस्टैम्प - स्थानीय समय के साथ भी चिह्नित किया जाता है, जिसके दौरान यह ऑपरेशन मास्टर पर vclock में दर्ज किया गया था जिसने इसे निष्पादित किया था। उसी समय, स्लेव ने अपने स्थानीय टाइमस्टैम्प की तुलना उस डेल्टा के टाइमस्टैम्प से की जो उसे प्राप्त हुआ था। अंतिम लाइन के लिए प्राप्त अंतिम वर्तमान टाइमस्टैम्प, निगरानी में दास प्रदर्शित करता है।
downstream विशेषता। यह दिखाता है कि मास्टर अपने विशेष दास के बारे में क्या जानता है। यह एसीके है जो दास उसे भेजता है। ऊपर प्रस्तुत downstream मतलब है कि पिछली बार नंबर 2 पर उनके दास उर्फ मास्टर ने उन्हें अपना वीएलओएल भेजा था, जो 5.1 था। यह मास्टर जानता है कि उसकी सभी पांच लाइनें, जो उसने अपने स्थान पर पूरी कीं, एक और नोड के लिए रवाना हो गईं।

XLOG नुकसान

गुरु के गिरने के साथ स्थिति पर विचार करें।

 lsn : 0 id: 3 replication : 1: <...> upstream : status: disconnected peer : lag: 3.9100646972656 e -05 idle: 1602.836148153 message: connect, called on fd 13, aka [::1]:37960 2: <...> upstream : status : follow idle : 0.65611373598222 peer : lag: 1.9550323486328 e -05 3: <...> vclock : {2: 2, 1: 5}

सबसे पहले, स्थिति बदल जाएगी। Lag नहीं बदलता है क्योंकि हमने जो लाइन लगाई थी, वही बनी हुई है, हमें कोई नया नहीं मिला। उसी समय, idle बढ़ रहा है, इस मामले में यह पहले से ही 1602 सेकंड के बराबर है, इतना समय मास्टर मर चुका था। और हम कुछ त्रुटि संदेश देखते हैं: कोई नेटवर्क कनेक्शन नहीं है।

ऐसी ही स्थिति में क्या करें? हम यह पता लगाते हैं कि हमारे मास्टर के साथ क्या हुआ, व्यवस्थापक को आकर्षित करें, सर्वर को पुनरारंभ करें, नोड बढ़ाएं। दोहराया प्रतिकृति किया जाता है, और जब मास्टर सिस्टम में प्रवेश करता है, तो हम इसे कनेक्ट करते हैं, इसकी XLOG की सदस्यता लेते हैं, उन्हें अपने लिए प्राप्त करते हैं और क्लस्टर स्थिर हो जाता है।

लेकिन एक छोटी सी समस्या है। कल्पना कीजिए कि हमारे पास एक दास था, जो किसी कारण से बंद हो गया था और लंबे समय तक अनुपस्थित था। इस दौरान, मास्टर, जिसने इसे सेवा दी, ने XLOG को हटा दिया। उदाहरण के लिए, डिस्क भरा हुआ है, कचरा संग्रहकर्ता ने लॉग एकत्र किया है। एक लौटता दास कैसे जारी रह सकता है? कोई रास्ता नहीं। क्योंकि क्लस्टर के साथ सिंक्रनाइज़ होने के लिए उसे जिस लॉग को लागू करने की आवश्यकता होती है, वे चले गए हैं और उनसे लेने के लिए कहीं नहीं हैं। इस मामले में, हम एक दिलचस्प त्रुटि देखेंगे: स्थिति अब disconnected नहीं हुई है, लेकिन stopped । और एक विशिष्ट संदेश: इस तरह के lsn से मेल खाता कोई लॉग फ़ाइल नहीं है।

 id: 3 replication : 1: <...> upstream : peer : status: stopped lag : 0.0001683235168457 idle : 9.4331328970147 message: 'Missing .xlog file between LSN 7 1: 5, 2: 2 and 8 1: 6, 2: 2' 2: <...> 3: <...> vclock : {2: 2, 1: 5}

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

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

क्लस्टर को स्ट्रिप करें या नए प्रतिकृति के लिए UUID का पुन: उपयोग करें: box.cfg{instance_uuid = uuid} ।

, . UUID space cluster, . , . UUID, master, JOIN, , UUID, , .

, UUID , space cluster , . . , , .

, - . , . , , .

Tarantool .

replication_connect_quorum: 2
replication_connect_timeout: 30
replication_sync_lag: 0.1

, , , , , , master' 0,1 . 30 . , . 0,1 . , .

Keep alive

, ip tables drop. , - 30 30 , , . , keep alive-.

keep alive- : box.cfg.replication_timeout .

master' , keep alive-, , . 4 master slave keep alive- , . master'.

, . 6 , 5 . 10 , 9 . .

, , . , master', . - . .

6 , 3. , . , 5 , 3 .

, :

.
, space cluster, . .

, Telegram-, . , GitHub, .

टारेंटूल प्रतिकृति: कॉन्फ़िगरेशन और उपयोग