आप डाउनटाइम पैदा किए बिना अपने उत्पादन कोडबेस / डेटाबेस स्कीमा को कैसे अपडेट करते हैं?

Question

उत्पादन सर्वर के आधार / डेटाबेस स्कीमा को बिना किसी डाउनटाइम के अपडेट करने के लिए कुछ तकनीकें क्या हैं?

Comments

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

— दान मैकग्राथ

@ डान मैकग्राथ: जो मान लेते हैं कि आप वास्तव में डाउनटाइम कर सकते हैं, मैं एक ऐसी प्रणाली के लिए काम करता हूं जो (सामान्य रूप से) साल में केवल 4 बार (क्वार्टर आउटेज) और हर बार अधिकतम 15 मिनट के लिए होती है (जिस दौरान ट्रैफिक कतार में है)। .. डेटाबेस परिवर्तन की भारी छानबीन की जाती है :)

— Matthieu M.

यह dba.stackexchange.com के लिए एक बड़ा सवाल होगा , जो कुछ ही घंटों में सार्वजनिक बीटा में चला जाता है।

— लैरी कोलमैन

Answer 1

आमतौर पर, मैंने जिन वेबसाइटों पर काम किया है, उनमें इस तरह की आवश्यकता लोड-बैलेन्कर्स के पीछे थी, या अलग-अलग विफल स्थान थे। इस नमूने में, मैं मान लूंगा कि आपको एक एकल लोड बैलेंसर, 2 वेब सर्वर (ए एंड बी) और 2 डेटाबेस सर्वर (एम एंड एन - आमतौर पर डीबी सर्वर लॉगशीपिंग के माध्यम से जुड़े हुए हैं - कम से कम SQL सर्वर दुनिया में )।

1. वेबसर्वर ए को लोड बैलेंसर से डिस्कनेक्ट किया जाना है (इसलिए आने वाले सभी ट्रैफ़िक बी पर जाते हैं)।
2. लॉग शिपिंग बंद कर दी गई है (DB Server M पहले अपडेट होने जा रहा है)।
3. Webserver को अपडेट करें। DB सर्वर M पर कॉन्फ़िगरेशन को इंगित करें।
4. परीक्षण और सत्यापित करें कि अद्यतन काम किया (आमतौर पर लोग सीधे आईपी पते को मार रहे हैं)।
5. लोड बैलेंसर सेट करें ताकि मौजूदा सत्र बी में जाते रहें। नए सत्र ए में जाएं।
6. बी एक्सपायर पर सभी सत्रों की प्रतीक्षा करें (आमतौर पर आधे घंटे या उससे अधिक हो सकता है, आमतौर पर हम ट्रैफ़िक देखते हैं और 1 घंटे का ब्रेक शेड्यूल किया गया है)।
7. अपडेट बी और एन।
8. परीक्षण और सत्यापित करें कि अपडेट ने काम किया।
9. लॉग शिपिंग को फिर से सेट करें और परीक्षण करें कि यह काम करता है।
10. नियमित ऑपरेशन के लिए लोड बैलेंसर सेट करें।

बहुत जटिल वेब अनुप्रयोगों में, 1-5 चरणों के रूप में वर्णित है जो पूरी रात हो सकता है और समय और आपातकालीन संपर्क नंबरों के साथ 50 पेज एक्सेल स्प्रेडशीट हो सकता है। ऐसी स्थितियों में, उपयोगकर्ताओं के लिए उपलब्ध सिस्टम को छोड़ते हुए, आधे सिस्टम को शाम 6 बजे से सुबह 6 बजे तक अपडेट किया जाता है। डीआर साइट के लिए अपडेट को संभालना आमतौर पर निम्नलिखित रात के लिए निर्धारित होता है - बस उम्मीद है कि पहले दिन कुछ भी नहीं टूटेगा।

जहां अपटाइम की आवश्यकता होती है, पैच को पहले QA पर्यावरण पर परीक्षण किया जाता है, जो आदर्श रूप से उत्पादन के समान हार्डवेयर है। यदि वे कोई व्यवधान नहीं दिखाते हैं, तो उन्हें नियमित समय पर लागू किया जा सकता है, जो आमतौर पर सप्ताहांत पर होता है।

Comments

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

— साठफुटेरसुडे

@ तंगुरेना, क्या आप उपरोक्त टिप्पणी का जवाब दे सकते हैं?

— साइनो

Answer 2

विशिष्ट डेटाबेस (उदाहरण के लिए ओरेकल) के लिए समानांतर में प्रश्नों को चलाने के दौरान डेटाबेस स्कीमा को बदलना संभव है। हालांकि इसके लिए कुछ आगे की योजना की आवश्यकता है।

उनके परिवर्तन लागू होने के लिए कुछ अड़चनें हैं:

• यह मौजूदा कोड के साथ काम करना चाहिए, जिसका अर्थ है कि कोड को स्कीमा के पुराने और नए दोनों संस्करणों से निपटना चाहिए
• यह डीबी पर ऐसा भार नहीं लादना चाहिए जिससे लेनदेन रुक जाएगा (मैं आपको देख रहा हूं CREATE INDEX)
• यह डेटा का नुकसान उठाना नहीं चाहिए (आप ड्रॉप नहीं कर सकते और पुनः तालिका नहीं बना सकते)

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

यदि आपका कोड पारदर्शी तरीके से परिवर्तन को संभाल नहीं सकता है, तो डेटाबेस को बदलने से पहले कोड को बदल दें।

फॉरवर्ड प्लानिंग पर सरल सलाह: अपने DB अनुरोधों में कॉलम के नामों को हमेशा स्पष्ट करें (उपयोग न करें SELECT * FROM)। इस तरह आपके पास पुराने अनुरोधों को दिखाने वाले नए कॉलम नहीं होंगे।

Comments

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

— मुर्दाघर।

@ मॉर्ग: वास्तव में नहीं। सुरक्षा के लिए आपको बाइंड चर का उपयोग करने की आवश्यकता होती है, जो कि मैं जिस फ्रेमवर्क का उपयोग करता हूं (कम से कम) उसे लिखने के लिए चर प्रदान करने की आवश्यकता होती है, और आउटपुट कॉलम के रूप में बिल्कुल वैसा ही होने की आवश्यकता होती है, इस प्रकार select *इसका मतलब है कि कोड टूटता है यदि a नया कॉलम जोड़ा गया है (इसे लिखने के लिए चर की कमी के लिए)। बेशक, यह एक जोरदार टाइप की गई भाषा का उपयोग करने का परिणाम हो सकता है।

— मैथ्यू एम।

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

— मुर्दाघर।

@ मॉर्ग: मैं यह देखने में विफल हूं कि कैसे select *अधिक विश्वसनीय और सुरक्षित है। अगर आपके पास होता था select one, two from ...तो आप केवल उपयोग कर रहे थे oneऔर two; यदि thirdतालिका में जोड़ा जाता है, तो आपके पास इसका कोई उपयोग नहीं है (यहां), इसलिए इसे पुनर्प्राप्त करने का कोई कारण नहीं है। और अगर आपको अचानक इसका उपयोग करने की आवश्यकता है, तो आप कोड को संशोधित करेंगे, इसलिए आप इस बिंदु पर क्वेरी को संशोधित कर सकते हैं!

— मैथ्यू एम।

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

— Matthieu M.

Answer 3

सभी सिस्टम नहीं कर सकते हैं, इसे एक तरीके से स्थापित करना होगा जो इसका समर्थन करता है।

उदाहरण के लिए, हमारे कुछ प्रमुख सिस्टम जिन्हें मैंने कुछ साल पहले अपग्रेड करने में मदद की थी, उन्हें 24/7 उपलब्ध होना चाहिए। इसमें ऑफियर यूजर इंटरफेस लेयर और बिजनेस लेयर के बीच एक शुद्ध संचार स्तरीय सहित कई स्तरों शामिल थे। जिस तरह से संचार परत को कोडित किया गया था, उसके कारण बिजनेस लेयर या डीबी स्कीमा के भविष्य के किसी भी बदलाव को वास्तविक आउटेज के बिना लागू किया जा सकता है। सबसे खराब स्थिति में, एक उपयोगकर्ता को 10-30 सेकंड के ठहराव का अनुभव होगा क्योंकि परिवर्तन प्रभावी हुए थे।

यदि परिवर्तन विशुद्ध रूप से व्यावसायिक परत में कोड परिवर्तन थे, तो उन्हें केवल मिलीसेकंड देरी के साथ कतारबद्ध किया जा सकता है और 'चक्रवात' किया जा सकता है।

यह ऐसा कर सकता है क्योंकि:

• संचार परत संदेशों को पकड़ सकती है। इससे हमें UI को नीचे लाने की आवश्यकता के बिना UI लेयर के अलावा किसी भी स्तर पर वास्तविक आउटेज की अनुमति मिलती है।
• व्यापार लेयर MVDB ने संभाला कहा जाता UniData । यह मेमोरी में सभी कोड रखता है। कोड संकलित करने के बाद, आप पुराने ऑब्जेक्ट की जगह नए ऑब्जेक्ट कोड को मेमोरी में मजबूर करने के लिए एक कमांड का उपयोग कर सकते हैं।

---

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

Answer 4

यहाँ एक अलग परिप्रेक्ष्य है, एम्बेडेड डेटाबेस सिस्टम और एम्बेडेड सिस्टम की दुनिया से। एंबेडेड सिस्टम में विभिन्न नेटवर्क / दूरसंचार अवसंरचना उपकरण शामिल हैं, और इस दायरे में वे अक्सर 99.999% (पांच 9s) अपटाइम के बारे में बात करते हैं।

हम (McObject) eXtremeDB उच्च उपलब्धता सहित एम्बेडेड डेटाबेस सिस्टम उत्पादों के eXtremeDB परिवार के विक्रेता हैं।

सबसे पहले, समझें कि "एम्बेडेड डेटाबेस" का मतलब है कि डेटाबेस सिस्टम एक पुस्तकालय है जो आपके एप्लिकेशन कोड के साथ संकलित और लिंक किया गया है; उस अर्थ में, यह आपके अनुप्रयोग में "एम्बेडेड" है।

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

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

व्यवहार में, इसका मतलब है कि आप अपने एप्लिकेशन का एक नया संस्करण बना सकते हैं (नए / गिराए गए तालिकाओं के साथ, नए / गिराए गए / बदले गए फ़ील्ड, नए / गिराए गए अनुक्रमित), अपने एप्लिकेशन के नए संस्करण को एक मास्टर में संलग्न करें, और फिर इसका कारण बनें नए मास्टर बनने के लिए नए प्रतिकृति (यानी नए प्रतिकृति के लिए एक विफलता को मजबूर करते हैं इसलिए यह मास्टर बन जाता है और पुराने मास्टर खुद को बंद कर देता है)। Voila, आपने अपने सिस्टम की उपलब्धता को बाधित किए बिना, अपने एप्लिकेशन को संस्करण N से N + 1 में स्थानांतरित कर दिया है। अब आप पुराने मास्टर और किसी भी अन्य प्रतिकृतियों के उन्नयन के बारे में N + 1 संस्करण पर जा सकते हैं।