🥇आपको अर्ध-तुल्यकालिक प्रतिकृति की आवश्यकता क्यों हो सकती है?

नमस्ते। व्लादिस्लाव रोडिन संपर्क में हैं। मैं वर्तमान में ओटीयूएस में सॉफ्टवेयर आर्किटेक्चर और हाई-स्ट्रेस सॉफ्टवेयर आर्किटेक्चर पर पाठ्यक्रम पढ़ाता हूं। नये पाठ्यक्रम प्रवाह की शुरूआत की प्रत्याशा में "हाई लोड आर्किटेक्ट" मैंने मूल सामग्री का एक छोटा टुकड़ा लिखने का निर्णय लिया जिसे मैं आपके साथ साझा करना चाहता हूं।

परिचय

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

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

प्रतिकृति

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

इसकी स्पष्ट सादगी के बावजूद, इस योजना के विभिन्न कार्यान्वयनों को वर्गीकृत करने के लिए कई विकल्प हैं:

क्लस्टर में भूमिकाओं के अनुसार (मास्टर-मास्टर या मास्टर-स्लेव)
भेजी गई वस्तुओं द्वारा (पंक्ति-आधारित, कथन-आधारित या मिश्रित)
नोड तुल्यकालन तंत्र के अनुसार

आज हम बिंदु 3 से निपटेंगे।

लेन-देन प्रतिबद्धता कैसे होती है?

यह विषय सीधे तौर पर प्रतिकृति से संबंधित नहीं है; इस पर एक अलग लेख लिखा जा सकता है, लेकिन चूंकि लेन-देन प्रतिबद्ध तंत्र को समझे बिना आगे पढ़ना बेकार है, इसलिए मैं आपको सबसे बुनियादी बातें याद दिला दूं। लेन-देन प्रतिबद्धता 3 चरणों में होती है:

डेटाबेस लॉग में लेनदेन लॉग करना।
डेटाबेस इंजन में लेनदेन का उपयोग करना।
ग्राहक को यह पुष्टि लौटाना कि लेनदेन सफलतापूर्वक लागू किया गया था।

विभिन्न डेटाबेस में, इस एल्गोरिदम में बारीकियां हो सकती हैं: उदाहरण के लिए, MySQL डेटाबेस के InnoDB इंजन में 2 लॉग होते हैं: एक प्रतिकृति (बाइनरी लॉग) के लिए, और दूसरा ACID (पूर्ववत करें/फिर से लॉग करें) बनाए रखने के लिए, जबकि PostgreSQL में एक लॉग है जो दोनों कार्य करता है (आगे लिखें लॉग = वाल)। लेकिन जो ऊपर प्रस्तुत किया गया है वह बिल्कुल सामान्य अवधारणा है, जो ऐसी बारीकियों को ध्यान में नहीं रखने की अनुमति देती है।

तुल्यकालिक (सिंक) प्रतिकृति

आइए लेनदेन प्रतिबद्ध एल्गोरिदम में प्राप्त परिवर्तनों को दोहराने के लिए तर्क जोड़ें:

डेटाबेस लॉग में लेनदेन लॉग करना।
डेटाबेस इंजन में लेनदेन का उपयोग करना।
सभी प्रतिकृतियों को डेटा भेजा जा रहा है.
सभी प्रतिकृतियों से पुष्टि प्राप्त करना कि उन पर लेनदेन पूरा हो गया है।
ग्राहक को यह पुष्टि लौटाना कि लेनदेन सफलतापूर्वक लागू किया गया था।

इस दृष्टिकोण से हमें कई नुकसान मिलते हैं:

क्लाइंट सभी प्रतिकृतियों पर परिवर्तन लागू होने की प्रतीक्षा करता है।
जैसे-जैसे क्लस्टर में नोड्स की संख्या बढ़ती है, हम यह संभावना कम करते जाते हैं कि राइट ऑपरेशन सफल होगा।

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

क्या हम केवल एक निश्चित प्रतिशत नोड्स से पुष्टि की प्रतीक्षा कर सकते हैं, उदाहरण के लिए, 51% (कोरम) से? हां, हम कर सकते हैं, लेकिन क्लासिक संस्करण में, सभी नोड्स से पुष्टि की आवश्यकता होती है, क्योंकि इस तरह हम क्लस्टर में पूर्ण डेटा स्थिरता सुनिश्चित कर सकते हैं, जो इस प्रकार की प्रतिकृति का निस्संदेह लाभ है।

अतुल्यकालिक (async) प्रतिकृति

आइए पिछले एल्गोरिदम को संशोधित करें। हम प्रतिकृतियों को "कुछ समय बाद" डेटा भेजेंगे, और "कुछ समय बाद" प्रतिकृतियों पर परिवर्तन लागू किए जाएंगे:

डेटाबेस लॉग में लेनदेन लॉग करना।
डेटाबेस इंजन में लेनदेन का उपयोग करना।
ग्राहक को यह पुष्टि लौटाना कि लेनदेन सफलतापूर्वक लागू किया गया था।
प्रतिकृतियों में डेटा भेजना और उनमें परिवर्तन लागू करना।

यह दृष्टिकोण इस तथ्य की ओर ले जाता है कि क्लस्टर तेजी से काम करता है, क्योंकि हम क्लाइंट को डेटा के प्रतिकृतियों तक पहुंचने और यहां तक कि प्रतिबद्ध होने तक इंतजार नहीं कराते हैं।

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

सेमीसिंक प्रतिकृति

अंततः हमें अर्ध-तुल्यकालिक प्रतिकृति प्राप्त होती है। इस प्रकार की प्रतिकृति बहुत प्रसिद्ध या बहुत आम नहीं है, लेकिन यह काफी रुचिकर है क्योंकि यह तुल्यकालिक और अतुल्यकालिक प्रतिकृति दोनों के लाभों को जोड़ सकती है।

आइए पिछले 2 दृष्टिकोणों को संयोजित करने का प्रयास करें। हम क्लाइंट को लंबे समय तक नहीं रखेंगे, लेकिन हमें यह आवश्यक होगा कि डेटा को दोहराया जाए:

डेटाबेस लॉग में लेनदेन लॉग करना।
डेटाबेस इंजन में लेनदेन का उपयोग करना।
प्रतिकृतियों को डेटा भेजना.
प्रतिकृति से पुष्टि प्राप्त करना कि परिवर्तन प्राप्त हो गए हैं (उन्हें "कुछ समय बाद" लागू किया जाएगा)।
ग्राहक को यह पुष्टि लौटाना कि लेनदेन सफलतापूर्वक लागू किया गया था।

कृपया ध्यान दें कि इस एल्गोरिदम के साथ, लेनदेन हानि केवल तभी होती है जब परिवर्तन प्राप्त करने वाले नोड और प्रतिकृति नोड दोनों विफल हो जाते हैं। ऐसी विफलता की संभावना कम मानी जाती है, और इन जोखिमों को स्वीकार किया जाता है।

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

हानि रहित सेमीसिंक प्रतिकृति

यदि आप थोड़ा सोचें, तो आप एल्गोरिदम के चरणों को उल्टा कर सकते हैं और इस परिदृश्य में फैंटम रीड की समस्या को ठीक कर सकते हैं:

डेटाबेस लॉग में लेनदेन लॉग करना।
प्रतिकृति डेटा भेजा जा रहा है.
प्रतिकृति से पुष्टि प्राप्त करना कि परिवर्तन प्राप्त हो गए हैं (उन्हें "कुछ समय बाद" लागू किया जाएगा)।
डेटाबेस इंजन में लेनदेन का उपयोग करना।
ग्राहक को यह पुष्टि लौटाना कि लेनदेन सफलतापूर्वक लागू किया गया था।

अब हम परिवर्तन तभी करते हैं जब उन्हें दोहराया गया हो।

उत्पादन

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

बस इतना ही। तुमसे मिलता हूं अवधि!

स्रोत: www.habr.com

आपको अर्ध-तुल्यकालिक प्रतिकृति की आवश्यकता क्यों पड़ सकती है?