हमारे पास कोई निरंतर एकीकरण सेटअप नहीं है (अभी तक)। लेकिन बहुत बार तैनाती करना चाहते हैं। एक दिन या तो एक बार।सेवा व्यवधान के बिना Django एप्लिकेशन को तैनात करें/कोई डाउनटाइम
हमारे पास एक अलग पोस्टग्रेस सर्वर के साथ एक सुंदर मानक Django एप्लिकेशन है। हम सामान्य किराए पर वीएम (कोई अमेज़ॅन या रैक स्पेस) का उपयोग करते हैं।
हम अपने आवेदन के डाउनटाइम को कैसे कम कर सकते हैं? शून्य डाउनटाइम के लिए सबसे अच्छा होगा। हमने दो बराबर एप्लिकेशन और दो डेटाबेस सर्वर के साथ एक सेटअप के बारे में सोचा और एक ऐप/डीबी सर्वर जोड़ी को दूसरे के बाद तैनात किया।
समस्या डेटा को लगातार बनाए रखती है। जबकि एक ऐप/डीबी सर्वर जोड़ी पुराने कोड के साथ सर्वर जोड़ी को अद्यतन कर रही है, उपयोगकर्ता की सेवा कर सकती है। लेकिन यदि उपयोगकर्ता डीबी को लिखते हैं तो हम अद्यतन जोड़ी पर स्विच करते समय डेटा खो देंगे। खासकर जब हम स्कीमा माइग्रेशन को दबाते हैं।
हम इसे कैसे प्रबंधित कर सकते हैं? यह एक बहुत ही आम समस्या होनी चाहिए लेकिन मुझे अच्छे जवाब नहीं मिल रहे हैं। आप इस समस्या को कैसे संभालेंगे?
मैंने ऊपर उठाया, लेकिन सिर्फ इसलिए कि आपके पास स्कीमा माइग्रेशन है जो मोंगोडीबी में माइग्रेट करने के लिए तत्काल आधार नहीं है। बस अपनी स्कीमा माइग्रेशन लिखें ताकि आप यह कर सकें: स्कीमा को अपग्रेड करें, नए एप को तैनात करें, ऐप के पुराने संस्करण के साथ असंगत होने वाली किसी भी बाधा को जोड़ने के लिए फिर से स्कीमा को अपग्रेड करें। अब आपकी सबसे बड़ी चिंता लॉक हो जाएगी: आप नहीं चाहते हैं कि आपका माइग्रेशन चालू होने पर ऐप गैर-उत्तरदायी न हो। कुछ परीक्षण करना आम तौर पर बताएगा कि यह एक समस्या है (लंबे समय से चलने वाला माइग्रेशन का मतलब है कि यह संभवतः होगा)। यदि ऐसा है, तो आपको प्रतिकृति की आवश्यकता है ... –
और फिर आप पहले प्राथमिक नहीं माइग्रेट करेंगे, फिर इसे प्राथमिक में प्रचारित करें और पुरानी प्राथमिक को प्राथमिक नहीं दें, फिर इसे माइग्रेट करें। इसका विवरण आपके प्रतिकृति समाधान पर निर्भर करेगा, लेकिन यह व्यवहार्य होना चाहिए। –
अच्छी तरह से NoSQL एक विकल्प नहीं है। हम पोस्टग्रेज़ से बहुत खुश हैं। क्या आप एक अच्छा प्रतिकृति समाधान की सिफारिश कर सकते हैं? – j7nn7k