8

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

सादगी के लिए एक बुनियादी वास्तुकला मानते हैं जहां आपके पास 2 आंसू संरचना है; लोड बैलेंसर के पीछे एप्लिकेशन सर्वर का संग्रह और फिर एक बहु-क्षेत्र आरडीएस डीबी का उपयोग करके एक दृढ़ता परत।

उदाहरणों के बेड़े (ऐप सर्वर) में वास्तविक कोड अपग्रेड करना आसान है। एक बहुत ही सरल अवलोकन के लिए एडब्ल्यूएस सेवा प्रत्येक नोड को कनेक्शन को बंद करने के बदले में अपग्रेड करती है, इसलिए प्रश्न में उदाहरण का उपयोग नहीं किया जा रहा है।

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

मुझे यह समझने की जरूरत है कि यह वास्तव में कैसे प्राप्त किया जाता है (उच्च स्तर) यह जानने के लिए कि डीबी माइग्रेशन करने का सबसे अच्छा तरीका/समय क्या है। मुझे लगता है कि वे इसे प्राप्त करने के कुछ तरीके हैं लेकिन मैं यह देखने के लिए संघर्ष कर रहा हूं कि वे इसे कैसे कर सकते हैं और 1.0.0 और 2.0.0 दोनों को नुकसान के बिना डेटा जारी रखने की अनुमति देते हैं।

यदि वे डीबी संरचना को पहले ऐप नोड अपग्रेड के साथ माइग्रेट करते हैं और साथ ही 1.0.0 का कैश संस्करण बनाते हैं। 1.0.0 ऐप से जुड़े उपयोगकर्ता डीबी के कैश किए गए संस्करण का उपयोग करते रहते हैं और 2.0.0 ऐप से जुड़े उपयोगकर्ता नए माइग्रेटेड डीबी पर बने रहते हैं। एक बार सभी ऐप नोड माइग्रेट हो जाते हैं, तो कैश किए गए डेटा को डीबी में विलय कर दिया जाता है।

ऐसा लगता है कि वे ऐसा कर सकते हैं क्योंकि विलय बहुत जटिल होगा लेकिन मैं एक और तरीका नहीं देख सकता। किसी भी पॉइंटर्स/सहायता की सराहना की जाएगी।

+0

क्या आपको इसका अच्छा जवाब मिला है? – jkerak

उत्तर

3

आपके एप्लिकेशन इंफ्रास्ट्रक्चर को एकाधिक एप्लिकेशन नोड्स में आने के बाद यह एक आम समस्या है। पुराने दिनों में, आप अपना रखरखाव "रखरखाव विंडोज़" के लिए ऑफ़लाइन ले सकते हैं जिसके दौरान आप:

  • एप्लिकेशन को "सिस्टम रखरखाव, जल्द ही वापस" पृष्ठ के साथ बदलें।
  • डेटाबेस माइग्रेशन (स्कीमा और/या डेटा)
  • तैनात नया आवेदन कोड
  • रखें आवेदन प्रदर्शन वापस ऑनलाइन

2015 में, और वास्तव में कई वर्षों के लिए इस दृष्टिकोण स्वीकार्य नहीं है। आपके उपयोगकर्ता 24/7 ऑपरेशन की उम्मीद करते हैं, इसलिए एक बेहतर तरीका होना चाहिए। बेशक, जवाब Database Refactorings के लिए पैटर्न की एक श्रृंखला है।

मूल अवधारणा हमेशा ध्यान में रखना करने के लिए ग्रहण करने के लिए आप दो संगत संस्करणों अपने आवेदन के बनाए रखने के लिए है, और वहाँ कोई तोड़ने में परिवर्तन इन दो संस्करणों के बीच हो सकता है। इसका मतलब है कि वर्तमान में आपके पास वर्तमान में उत्पादन (v1.0.0) है और (v2.0.0) जो तैनात किया गया है। इन दोनों संस्करणों को एक ही स्कीमा पर काम करना चाहिए। एक बार v2.0.0 सभी एप्लिकेशन सर्वरों पर पूरी तरह से तैनात किया जाता है, तो आप v3.0.0 विकसित कर सकते हैं जो आपको अंतिम डेटाबेस परिवर्तनों को पूरा करने की अनुमति देता है।

संबंधित मुद्दे