पिछले हफ्ते, मैं नॉर्डिक पीजीडे 2018 में था और मैंने अपने द्वारा लिखे गए टूल के बारे में कुछ बातचीत की थी, जिसका नाम है pglupgrad , प्रतिकृति क्लस्टर सेटअप में PostgreSQL प्रमुख संस्करण उन्नयन को स्वचालित करने के लिए। मैं काफी खुश था कि यह सुना गया है और विभिन्न समुदायों के कुछ अन्य लोग तार्किक प्रतिकृति का उपयोग करके लगभग शून्य डाउनटाइम अपग्रेड के बारे में मीटअप और अन्य सम्मेलनों में बातचीत कर रहे हैं। यह देखते हुए कि मैंने PGDAY'17 रूस, PGConf.EU 2017 को वारसॉ में और अंत में ब्रुसेल्स में FOSDEM PGDay 2018 में दिया था, मैंने सोचा कि इस प्रस्तुति को उन लोगों के लिए उपलब्ध रखने के लिए एक ब्लॉग पोस्ट बनाना बेहतर है जो कर सकते हैं उपरोक्त किसी भी सम्मेलन में इसे न बनाएं। यदि आप सीधे बात करना चाहते हैं और इस ब्लॉग पोस्ट को पढ़ना छोड़ना चाहते हैं तो यहां आपका लिंक है:क्लाउड में पोस्टग्रेएसक्यूएल क्लस्टर्स के नियर-जीरो डाउनटाइम ऑटोमेटेड अपग्रेड्स
इस उपकरण को विकसित करने के पीछे मुख्य प्रेरणा प्रमुख संस्करण उन्नयन के दौरान डाउनटाइम को कम करने के लिए एक समाधान का प्रस्ताव करना था जो दुर्भाग्य से लगभग हर उस व्यक्ति को प्रभावित करता है जो PostgreSQL का उपयोग करता है। वर्तमान में, हमारे पास ऐसा उपकरण नहीं है जो PostgreSQL उपयोगकर्ताओं को डाउनटाइम के बिना अपने डेटाबेस को अपग्रेड करने की अनुमति देता है और यह स्पष्ट रूप से कई उपयोगकर्ताओं, विशेष रूप से व्यवसायों के लिए एक दर्द बिंदु है। और, अगर हमें अपग्रेड समस्या का समाधान करना है तो हमें एक से अधिक सर्वर (अब से क्लस्टर के रूप में संदर्भित किया जाएगा) के बारे में सोचना चाहिए, केवल इसलिए कि बहुत से लोग अब केवल एक डेटाबेस सर्वर का उपयोग नहीं करते हैं। सबसे आम परिदृश्य में भौतिक स्ट्रीमिंग प्रतिकृति सेटअप या तो उच्च उपलब्धता उद्देश्यों के लिए या रीड क्वेरी को स्केल करना है।
डेटाबेस अपग्रेड
समाधान में गोता लगाने से पहले, आइए इस बारे में थोड़ी चर्चा करें कि डेटाबेस अपग्रेड सामान्य रूप से कैसे काम करता है। डेटाबेस अपग्रेड के लिए चार मुख्य संभावित दृष्टिकोण हैं:
- डेटाबेस के लिए पहला तरीका यह होगा कि वे अपने भंडारण प्रारूप को समान रखें या कम से कम सभी संस्करणों में संगत रहें। हालांकि, लंबे समय तक इसकी गारंटी देना कठिन है क्योंकि नई सुविधाओं के लिए डेटा को संग्रहीत करने के तरीके में बदलाव की आवश्यकता हो सकती है या ठीक से काम करने के लिए अधिक मेटाडेटा जानकारी जोड़ सकते हैं। साथ ही, डेटा संरचनाओं को अनुकूलित करके अक्सर प्रदर्शन में सुधार किया जाता है।
- दूसरा तरीका है पुराने सर्वर की लॉजिकल कॉपी (डंप) बनाना और उसे नए सर्वर में लोड करना। यह सबसे पारंपरिक तरीका है जिसके लिए पुराने सर्वर को प्रक्रिया के दौरान कोई अपडेट प्राप्त नहीं करने की आवश्यकता होती है और इसके परिणामस्वरूप लंबे समय तक डाउनटाइम होता है। बड़े डेटाबेस पर घंटों या दिनों का भी।
- तीसरा विकल्प है डेटा को पुराने फॉर्मेट से नए फॉर्मेट में बदलना। यह या तो नई प्रणाली के चलने के दौरान किया जा सकता है, लेकिन प्रदर्शन जुर्माना लगता है जिसका अनुमान लगाना कठिन है क्योंकि यह डेटा एक्सेस पैटर्न पर निर्भर करता है, या इसे ऑफ़लाइन किया जा सकता है जब सर्वर डाउन हो, फिर से लंबे समय तक डाउनटाइम्स (हालांकि अक्सर दूसरी विधि से छोटा होता है)।
- चौथी विधि डेटाबेस को सहेजने और पुनर्स्थापित करने के लिए तार्किक डंप का उपयोग करना है इस बीच हो रहे परिवर्तनों को कैप्चर करते समय और प्रारंभिक पुनर्स्थापना समाप्त होने के बाद तार्किक रूप से उन्हें नए डेटाबेस में दोहराना। इस पद्धति के लिए कई घटकों के ऑर्केस्ट्रेशन की आवश्यकता होती है, लेकिन यह उस समय की मात्रा को भी कम कर देता है जब डेटाबेस प्रश्नों का उत्तर नहीं दे सकता है।
PostgreSQL में अपग्रेड तरीके
PostgreSQL अपग्रेड का मिलान ऊपर सूचीबद्ध चार विधियों से किया जा सकता है। उदाहरण के लिए, PostgreSQL माइनर रिलीज़, जिसमें नई सुविधाएँ नहीं हैं, लेकिन केवल सुधार हैं, मौजूदा डेटा प्रारूप को नहीं बदलते हैं और पहले दृष्टिकोण को फिट करते हैं। दूसरे दृष्टिकोण के लिए, PostgreSQL pg_dump और pg_restore नामक उपकरण प्रदान करता है जो तार्किक बैकअप और पुनर्स्थापना करते हैं। pg_upgrad टूल भी है (यह एक contrib मॉड्यूल था और PostgreSQL 9.5 में मुख्य ट्री में चला गया) जो पुराने डेटा निर्देशिका को नए में ऑफ़लाइन (सर्वर नहीं चल रहा है) रूपांतरण करता है, जो तीसरे विकल्प में फिट हो सकता है। चौथे दृष्टिकोण के लिए, उन्नयन के लिए स्लोनी जैसे तीसरे पक्ष के ट्रिगर-आधारित समाधान हैं, लेकिन उनके पास कुछ चेतावनी हैं जिन्हें हम बाद में कवर करेंगे।
अपग्रेड के पारंपरिक तरीके केवल प्राथमिक सर्वर को अपग्रेड करें जबकि प्रतिकृति सर्वर को बाद में फिर से बनाना होगा (ऑफ़लाइन रूपांतरण) . यह क्लस्टर उपलब्धता और क्षमता दोनों के साथ अतिरिक्त समस्याएं पैदा करता है, इसलिए प्रभावी रूप से कथित डाउनटाइम को बढ़ाता है अनुप्रयोगों और उपयोगकर्ताओं दोनों के बिंदु से डेटाबेस का। तार्किक प्रतिकृति प्रतिकृति की अनुमति देता है जबकि सिस्टम अप-एंड-रनिंग . है और इस बीच परीक्षण प्रयास को संभाला जा सकता है (ऑनलाइन रूपांतरण) ।
अलग-अलग परिवेशों के लिए अलग-अलग अपग्रेड विधियां लागू होती हैं। उदाहरण के लिए, pg_dump बहुत पुराने संस्करणों (यानी 7.0) . से अपग्रेड की अनुमति देता है हाल की रिलीज़ के लिए, इसलिए यदि आप PostgreSQL का एक प्राचीन संस्करण चला रहे हैं, तो सबसे अच्छा तरीका pg_dump/restore का उपयोग करना है (और अब इसे करना बेहतर है!) यदि आपका PostgreSQL संस्करण 8.4 और बाद का है आप pg_upgrad . का उपयोग कर सकते हैं . अगर आप PostgreSQL 9.4 और बाद के संस्करण . का उपयोग कर रहे हैं इसका मतलब है कि आपके पास इन-कोर “लॉजिकल डिकोडिंग” . है और आप pglogic . का उपयोग कर सकते हैं उन्नयन के साधन के रूप में विस्तार। अंत में, यदि आप PostgreSQL 10 . का उपयोग कर रहे हैं , आपके पास अपने डेटाबेस को PostgreSQL 11 और बाद में . में अपग्रेड करने का मौका होगा (एक बार उपलब्ध हो जाने पर) इन-कोर “तार्किक प्रतिकृति” . का उपयोग करके (याय!)।
उन्नयन के लिए तार्किक प्रतिकृति
तार्किक प्रतिकृति . का उपयोग करके PostgreSQL को अपग्रेड करने का विचार कहां है? से आ रहा है?स्पष्ट रूप से, pglogic pg_upgrad . जैसे अपग्रेड उद्देश्य का खुले तौर पर दावा नहीं करता है करता है (कॉन्फ्रेंस पार्टी में pglogic के खिलाफ यह एक तर्क था ), लेकिन इसका मतलब यह नहीं है कि हम अपग्रेड के लिए टूल का उपयोग नहीं कर सकते हैं। वास्तव में, जब pglogic डिज़ाइन किया गया था, तो लगभग-शून्य डाउनटाइम अपग्रेड को एक्सटेंशन के डेवलपर्स द्वारा अपेक्षित उपयोग-मामलों में से एक माना जाता था।
भौतिक प्रतिकृति के विपरीत, जो डिस्क पर कच्चे डेटा में परिवर्तन को कैप्चर करता है, तार्किक प्रतिकृति डेटाबेस में व्यक्तिगत रिकॉर्ड में तार्किक परिवर्तनों को पकड़ती है और उन्हें दोहराती है। तार्किक रिकॉर्ड प्रमुख रिलीज़ में काम करते हैं , इसलिए तार्किक प्रतिकृति अपग्रेड करने के लिए उपयोग की जा सकती है एक रिलीज से दूसरी रिलीज। संस्करण उन्नयन के साधन के रूप में तार्किक प्रतिकृति का उपयोग करने का विचार नया होने से बहुत दूर है, ट्रिगर-आधारित प्रतिकृति उपकरण ट्रिगर के माध्यम से परिवर्तनों को कैप्चर और भेजकर तार्किक तरीके से उन्नयन कर रहे हैं (क्योंकि ट्रिगर डेटाबेस संस्करणों की परवाह किए बिना भी काम कर सकते हैं! )।
यदि आप न्यूनतम डाउनटाइम अपग्रेड के लिए ट्रिगर-आधारित प्रतिकृति समाधान का उपयोग कर सकते हैं, तो आपको इसके बजाय तार्किक प्रतिकृति क्यों पसंद करनी चाहिए? ट्रिगर-आधारित तंत्र में, सभी परिवर्तन ट्रिगर का उपयोग करके कैप्चर किए जाते हैं और क्यू टेबल में लिखे जाते हैं। यह प्रक्रिया लेखन कार्यों को दोगुना करती है, लॉग फाइलों को दोगुना करती है, और सिस्टम को धीमा कर देती है क्योंकि सभी परिवर्तनों को दो बार लिखा जाना होता है; परिणामस्वरूप अधिक डिस्क I/O और स्रोत सर्वर पर लोड होता है। इसके विपरीत, इन-कोर तार्किक प्रतिकृति (वही pglogic विस्तार के लिए जाता है) तार्किक डिकोडिंग के शीर्ष पर बनाया गया है। लॉजिकल डिकोडिंग एक ऐसा तंत्र है जो वाल फाइलों से तार्किक परिवर्तनों (INSERT/UPDATE/DELETE) में जानकारी निकालता है। चूंकि WAL तंत्र के डेटा का उपयोग लेन-देन लॉग को डिकोड करके किया जाता है, इसलिए कोई लेखन प्रवर्धन नहीं है जैसा कि ट्रिगर-आधारित प्रतिकृति समाधानों के मामले में होता है, इसलिए यह विधि बेहतर प्रदर्शन करती है . नतीजतन, तार्किक डिकोडिंग आधारित समाधान ट्रिगर-आधारित समाधानों की तुलना में सिस्टम पर कम प्रभाव डालते हैं।
निष्कर्ष
इस प्रारंभिक पोस्ट में, मैं एक विचार देना चाहता था कि हमें प्रमुख संस्करण उन्नयन के दौरान न्यूनतम डाउनटाइम प्राप्त करने के लिए तार्किक प्रतिकृति का उपयोग करने पर विचार क्यों करना चाहिए। हम आगामी पोस्ट में टूल के आर्किटेक्चर और कार्यान्वयन के विवरण के साथ जारी रखेंगे।
