ऑनलाइन अपग्रेड पर प्रगति

पिछले कुछ महीनों में मैं एक्सल प्रोजेक्ट के हिस्से के रूप में बहुत बड़े डेटाबेस के लिए ऑनलाइन अपग्रेड पर काम कर रहा हूं और मैं इस विषय पर अपने विचार साझा करना चाहता हूं और हमने हाल ही में क्या प्रगति की है।

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

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

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

जैसा कि आप कल्पना कर सकते हैं कि इस प्रक्रिया में काफी समय लग सकता है। प्रदर्शन में सुधार 8.4 में pg_restore के लिए -j विकल्प के साथ जोड़ा गया था जहाँ आप निर्दिष्ट कर सकते थे कि कितने समानांतर कार्य चलाना है। यह समानांतर में कई तालिकाओं (इंडेक्स, आदि) को पुनर्स्थापित करना संभव बनाता है जिससे कस्टम प्रारूप डंप के लिए पुनर्स्थापना प्रक्रिया तेज हो जाती है। 9.3 संस्करण ने pg_dump के समान विकल्प जोड़ा, प्रदर्शन को और भी बेहतर बनाया। लेकिन यह देखते हुए कि डेटा की मात्रा कितनी तेजी से बढ़ रही है, अपग्रेड के लिए आवश्यक समय में कोई गंभीर लाभ प्राप्त करने के लिए समानांतरीकरण ही पर्याप्त नहीं है।

फिर PostgreSQL 9.0 में pg_upgrad नामक एक उपयोगिता आई। Pg_upgrad केवल संरचनाओं को डंप करता है और उन्हें नए क्लस्टर में पुनर्स्थापित करता है। लेकिन यह डेटा फ़ाइलों की प्रतिलिपि बनाता है क्योंकि वे डिस्क पर हैं जो उन्हें तार्किक प्रारूप में डंप करने और फिर से डालने से कहीं अधिक तेज़ है। यह छोटे डेटाबेस के लिए काफी अच्छा है क्योंकि इसका अर्थ है मिनटों या घंटों की सीमा में डाउनटाइम, कई परिदृश्यों के लिए स्वीकार्य समय। लिंक मोड भी है जो सिर्फ हार्ड लिंक (विंडोज़ पर जंक्शन पॉइंट) बनाता है जो इस प्रक्रिया को और भी तेज़ बनाता है। लेकिन मेरे व्यक्तिगत दृष्टिकोण से इस तरह के सेटअप को प्रोडक्शन मास्टर सर्वर पर चलाना बहुत खतरनाक है। मैं संक्षेप में बताऊंगा कि क्यों। यदि कुछ गलत हो जाता है, तो एक बार जब आप अपना नया सर्वर शुरू करते हैं जिसे लिंक मोड का उपयोग करके अपग्रेड किया गया था, तो आप अचानक उत्पादन डेटाबेस के बिना हैं और असफल होना है, या इससे भी बदतर, आपको बैकअप से पुनर्स्थापित करना होगा। इसका मतलब है कि आप न केवल अपग्रेड करने में विफल रहे बल्कि आपने अतिरिक्त डाउनटाइम का कारण बना दिया! अगली बार स्वीकृति मिलने का सौभाग्य।

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

PostgreSQL 9.4 के साथ लॉजिकल डिकोडिंग फीचर आता है जो एक नए और बेहतर ऑनलाइन अपग्रेड समस्या समाधान को डिजाइन करने के लिए एक नई शुरुआत प्रदान करता है। AXLE प्रोजेक्ट के हिस्से के रूप में हमने जो किया, वह एक ऐसा टूल बनाना है जो ऊपर वर्णित तकनीकों के साथ लॉजिकल डिकोडिंग को जोड़ता है। समाधान पिछले दृष्टिकोणों की अधिकांश समस्याओं को हल करता है। यूनी-डायरेक्शनल रेप्लिकेशन पोस्टग्रेएसक्यूएल एक्सटेंशन (यूडीआर संक्षेप में) राइट फॉरवर्ड लॉग (वाल) के लॉजिकल डिकोडिंग का उपयोग करके तार्किक प्रतिकृति करता है। इसके लिए धन्यवाद, मास्टर सर्वर पर प्रभाव लगभग भौतिक स्ट्रीमिंग प्रतिकृति के बराबर है, इसलिए चल रहे अपग्रेड के कारण अतिरिक्त भार चल रहे सिस्टम पर न्यूनतम है। साथ ही यह भौतिक और तार्किक बैकअप दोनों का उपयोग करके नए नोड्स को आरंभ करने के लिए उपकरण प्रदान करता है। आप मौजूदा भौतिक स्टैंडबाय को यूडीआर स्टैंडबाय में भी बदल सकते हैं। और क्योंकि यह एक तार्किक प्रतिकृति प्रणाली है, इसलिए इसे इस तरह से डिजाइन करना संभव है जो क्रॉस-वर्जन प्रतिकृति का समर्थन करता है।

इसका मतलब यह है कि अब हम कम से कम डाउनटाइम के साथ, कम समय में और रनिंग सिस्टम पर न्यूनतम प्रभाव के साथ प्रमुख PostgreSQL संस्करण का ऑनलाइन अपग्रेड करने के लिए pg_upgrad के संयोजन में UDR का उपयोग कर सकते हैं।

एक उदाहरण कि यह व्यवहार में कैसे दिख सकता है:

• मौजूदा इंस्टेंस का pg_baseबैकअप करें.
• यूडीआर प्रतिकृति को मूल उदाहरण और बेसबैकअप द्वारा बनाए गए उदाहरण के बीच सेट करें।
• नए इंस्टेंस को Pg_अपग्रेड करें।
• यूडीआर को इस बीच हुए परिवर्तनों को फिर से चलाने दें।
• ट्रैफ़िक को नए इंस्टेंस पर स्विच करें।

अधिक विस्तृत निर्देशों के साथ कैसे करें के लिए PostgreSQL विकी पर UDR ऑनलाइन अपग्रेड मार्गदर्शिका देखें। UDR स्रोत PostgreSQL git सर्वर (bdr-plugin/अगली शाखा) पर 2ndquadrant_bdr रिपॉजिटरी में उपलब्ध हैं।

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

मेरी आशा है कि इस प्रयास का अर्थ यह होगा कि जब PostgreSQL 9.4 और इसके बाद के संस्करण से एक नए प्रमुख संस्करण में अपग्रेड करने की बात आती है तो डाउनटाइम विचार अब कोई समस्या नहीं हैं।

इन परिणामों की ओर ले जाने वाले शोध को अनुदान समझौते n° 318633 के तहत यूरोपीय संघ के सातवें फ्रेमवर्क प्रोग्राम (FP7/2007-2013) से धन प्राप्त हुआ है।