🐋 🚥 👨🏻‍🏫 डेटाबेस अद्यतन और शून्य-डाउनटाइम परिनियोजन 👨🏾‍💻 ☝🏻 💂

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

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

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

एक नया क्षेत्र जोड़ना
क्षेत्र विलोपन
फ़ील्ड का नाम बदलें
फ़ील्ड प्रकार परिवर्तन
फ़ील्ड को किसी अन्य डेटा संरचना में स्थानांतरित करना (उदाहरण के लिए, अपभ्रंश के मामले में)

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

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

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

यदि डेटाबेस ट्रिगर्स का समर्थन करता है

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

यदि ट्रिगर्स का उपयोग करना संभव नहीं है (जैसा कि कई NoSQL समाधानों के साथ होता है)

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

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

यह नोटिस करना आसान है कि सिस्टम को अपडेट करते समय शून्य डाउनटाइम सुनिश्चित करना एक बोझिल और नाजुक प्रक्रिया है, इसलिए यह केवल तभी परेशान करने के लिए समझ में आता है जब व्यवसाय से संबंधित आवश्यकता हो। लेकिन भले ही सिस्टम उपलब्धता की आवश्यकताएं काफी कम हों (उदाहरण के लिए, प्रति वर्ष 99% और नियोजित सिस्टम अपडेट के लिए विंडो 24 घंटे), नए संस्करण को स्थापित करने के लिए आवश्यक डेटा रूपांतरण में अभी भी अधिक समय लग सकता है। इसलिए, यदि आप बड़ी मात्रा में डेटा संग्रहीत करने की योजना बनाते हैं, तो आपको ऐसे समाधानों के उपयोग के लिए पहले से तैयार रहना होगा।

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

डेटाबेस अद्यतन और शून्य-डाउनटाइम परिनियोजन

यदि डेटाबेस ट्रिगर्स का समर्थन करता है

यदि ट्रिगर्स का उपयोग करना संभव नहीं है (जैसा कि कई NoSQL समाधानों के साथ होता है)

More articles: