यह समय है।
लगभग एक साल पहले, हमने मूल तार्किक प्रतिकृति के समर्थन के साथ PostgreSQL 10 प्रकाशित किया था। तार्किक प्रतिकृति के उपयोगों में से एक PostgreSQL प्रमुख संस्करणों के बीच कम या बिना डाउनटाइम के उन्नयन की अनुमति देना है। अब तक, PostgreSQL 10 देशी तार्किक प्रतिकृति के साथ एकमात्र PostgreSQL रिलीज़ था, इसलिए इस तरह से अपग्रेड करने के कई अवसर नहीं थे। (लॉजिकल प्रतिकृति का उपयोग विभिन्न ऑपरेटिंग सिस्टम या सीपीयू आर्किटेक्चर पर इंस्टेंस के बीच डेटा को स्थानांतरित करने के लिए या विभिन्न निम्न-स्तरीय कॉन्फ़िगरेशन सेटिंग्स जैसे कि ब्लॉक आकार या लोकेल - साइडग्रेडिंग के साथ किया जा सकता है।) अब जब पोस्टग्रेएसक्यूएल 11 निकट है, तो वहां होगा इस कार्यक्षमता का उपयोग करने के अधिक कारण।
आइए पहले PostgreSQL इंस्टॉलेशन को अपग्रेड करने के तीन मुख्य तरीकों की तुलना करें:
- pg_dump और पुनर्स्थापित करें
- pg_upgrad
- तार्किक प्रतिकृति
हम इन विधियों की तुलना मजबूती, गति, आवश्यक डाउनटाइम और प्रतिबंधों के संदर्भ में कर सकते हैं (और भी बहुत कुछ, लेकिन हमें इस लेख के लिए कहीं रुकना होगा)।
pg_dump और पुनर्स्थापना यकीनन सबसे मजबूत तरीका है, क्योंकि यह सबसे अधिक परीक्षण किया गया है और दशकों से उपयोग में है। यह क्या संभाल सकता है इसके संदर्भ में भी बहुत कम प्रतिबंध हैं। ऐसे डेटाबेस बनाना संभव है जिन्हें डंप और पुनर्स्थापित नहीं किया जा सकता है, जिसमें ज्यादातर विशेष वस्तु निर्भरता संबंध शामिल हैं, लेकिन वे दुर्लभ हैं और आमतौर पर हतोत्साहित करने वाले अभ्यास शामिल हैं।
डंप और पुनर्स्थापना विधि के साथ समस्या निश्चित रूप से यह है कि इसे डंप और पुनर्स्थापना संचालन चलाने के लिए पूरे समय के लिए डाउनटाइम की प्रभावी रूप से आवश्यकता होती है। जबकि स्रोत डेटाबेस अभी भी पठनीय और लिखने योग्य है, जबकि प्रक्रिया चलती है, डंप की शुरुआत के बाद स्रोत डेटाबेस में कोई भी अपडेट खो जाएगा।
pg_upgrad डेटा फ़ाइलों को तार्किक पाठ्य रूप में डंप किए बिना सीधे स्थानांतरित करके pg_dump प्रक्रिया में सुधार करता है। ध्यान दें कि pg_upgrad अभी भी स्कीमा को कॉपी करने के लिए आंतरिक रूप से pg_dump का उपयोग करता है, लेकिन डेटा का नहीं। जब pg_upgrad नया था, तो इसकी मजबूती पर सवाल उठाया गया था, और इसने कुछ डेटाबेस को गलत तरीके से अपग्रेड किया था। लेकिन pg_upgrad अब काफी परिपक्व और अच्छी तरह से परीक्षण किया गया है, इसलिए किसी को भी इस कारण से इसका उपयोग करने में संकोच करने की आवश्यकता नहीं है। जबकि pg_upgrad चलता है, डेटाबेस सिस्टम डाउन है। लेकिन कोई चुनाव कर सकता है कि pg_upgrad कितने समय तक चलता है। डिफ़ॉल्ट कॉपी मोड में, कुल रन टाइम स्कीमा को डंप करने और पुनर्स्थापित करने के समय से बना होता है (जो आमतौर पर बहुत तेज़ होता है, जब तक कि किसी के पास हजारों टेबल या अन्य ऑब्जेक्ट न हों) साथ ही डेटा फ़ाइलों की प्रतिलिपि बनाने का समय, जो निर्भर करता है डेटाबेस कितना बड़ा है (और I/O सिस्टम, फाइल सिस्टम, आदि)।
वैकल्पिक लिंक मोड में, डेटा फ़ाइलों को नई डेटा निर्देशिका से हार्ड-लिंक किया जाता है, ताकि समय हर बाइट की प्रतिलिपि बनाने के बजाय प्रति फ़ाइल एक छोटा कर्नेल ऑपरेशन करने का समय हो। दोष यह है कि यदि अपग्रेड में कुछ भी गलत होता है या आपको पुराने इंस्टॉलेशन पर वापस जाने की आवश्यकता है, तो यह ऑपरेशन आपके पुराने डेटाबेस को नष्ट कर देगा। (मैं समर्थित फ़ाइल सिस्टम पर रिफ़लिंक या फ़ाइल क्लोन संचालन का उपयोग करके PostgreSQL 12 के लिए दोनों-दुनिया के सर्वश्रेष्ठ समाधान पर काम कर रहा हूं।)
तार्किक प्रतिकृति यहाँ गुच्छा का सबसे नया है, इसलिए किंक को काम करने में शायद कुछ समय लगेगा। यदि आपके पास अन्वेषण और अन्वेषण करने का समय नहीं है, तो हो सकता है कि यह अभी जाने का तरीका न हो। (बेशक, लोग पोस्टग्रेएसक्यूएल को अपग्रेड करने के लिए कई वर्षों से अन्य गैर-कोर लॉजिकल प्रतिकृति समाधान जैसे स्लोनी, लोंडिस्ट, और पीजीलॉजिकल का उपयोग कर रहे हैं, इसलिए सिद्धांतों के साथ बहुत अनुभव है, यदि विवरण के साथ नहीं।)
अपग्रेड करने के लिए तार्किक प्रतिकृति का उपयोग करने का लाभ यह है कि डेटा सिंक्रनाइज़ेशन होने पर एप्लिकेशन पुराने इंस्टेंस के विरुद्ध चलना जारी रख सकता है। क्लाइंट कनेक्शन स्विच ओवर होने पर केवल एक छोटा आउटेज होना चाहिए। इसलिए जबकि तार्किक प्रतिकृति का उपयोग करते हुए अपग्रेड संभवतः कॉपी मोड में pg_upgrad का उपयोग करने की तुलना में धीमी गति से शुरू होता है (और निश्चित रूप से हार्डलिंक मोड का उपयोग करने की तुलना में धीमा), यह बहुत मायने नहीं रखता क्योंकि वास्तविक डाउनटाइम बहुत कम हो सकता है।
ध्यान दें कि तार्किक प्रतिकृति वर्तमान में स्कीमा परिवर्तनों को दोहराती नहीं है। इस प्रस्तावित अपग्रेड प्रक्रिया में, स्कीमा को अभी भी pg_dump के माध्यम से कॉपी किया जाता है, लेकिन बाद के स्कीमा परिवर्तनों को आगे नहीं बढ़ाया जाता है। तार्किक प्रतिकृति के साथ उन्नयन में कुछ अन्य प्रतिबंध भी हैं। कुछ ऑपरेशन तार्किक प्रतिकृति द्वारा कैप्चर नहीं किए जाते हैं:बड़ी वस्तुएं, TRUNCATE, अनुक्रम परिवर्तन। हम इन मुद्दों के समाधान के बारे में बाद में चर्चा करेंगे।
यदि आपके पास कोई भौतिक स्टैंडबाय है (और यदि नहीं, तो आप क्यों नहीं?), तरीकों के बीच विचार करने के लिए कुछ अंतर भी हैं। किसी भी विधि के साथ, आपको अपग्रेड किए गए इंस्टेंस के लिए नए भौतिक स्टैंडबाय बनाने की आवश्यकता है। डंप और पुनर्स्थापना के साथ-साथ तार्किक प्रतिकृति के साथ, उन्हें अपग्रेड शुरू होने से पहले रखा जा सकता है ताकि एक बार पुनर्स्थापना या तार्किक प्रतिकृति प्रारंभिक सिंक पूरा हो जाने पर स्टैंडबाय तैयार हो जाए, प्रतिकृति विलंब के अधीन।
pg_upgrad के साथ, प्राइमरी का अपग्रेड पूरा होने के बाद नए स्टैंडबाय बनाने होंगे। (pg_upgrad प्रलेखन इसका अधिक विस्तार से वर्णन करता है।) यदि आप उच्च उपलब्धता के लिए भौतिक स्टैंडबाय पर भरोसा करते हैं, तो आपके द्वारा नए इंस्टेंस पर स्विच करने से पहले स्टैंडबाय होना चाहिए, इसलिए स्टैंडबाय का सेटअप आपके समग्र समय की गणना को प्रभावित कर सकता है।
लेकिन वापस तार्किक प्रतिकृति के लिए। यहां बताया गया है कि तार्किक प्रतिकृति के साथ अपग्रेड कैसे किया जा सकता है:
0. तार्किक प्रतिकृति के लिए पुराना उदाहरण तैयार किया जाना चाहिए। इसके लिए http://www.postgresql.org/docs/10/static/logic-replication-config.html (मुख्य रूप से wal_level = logical के तहत वर्णित कुछ कॉन्फ़िगरेशन सेटिंग्स की आवश्यकता है। . यदि यह पता चलता है कि आपको वे परिवर्तन करने की आवश्यकता है, तो उन्हें सर्वर पुनरारंभ करने की आवश्यकता होगी। इसलिए समय से पहले इसे अच्छी तरह से जांच लें। यह भी जांचें कि pg_hba.conf पुराने उदाहरण पर नए उदाहरण से कनेक्शन स्वीकार करने के लिए स्थापित किया गया है। (इसे बदलने के लिए केवल पुनः लोड करने की आवश्यकता है।)
1. नया PostgreSQL संस्करण स्थापित करें। आपको कम से कम सर्वर पैकेज और क्लाइंट पैकेज की आवश्यकता है जिसमें pg_dump हो। कई पैकेजिंग अब कई संस्करणों को साथ-साथ स्थापित करने की अनुमति देती हैं। यदि आप वर्चुअल मशीन या क्लाउड इंस्टेंस चला रहे हैं, तो नए होस्ट पर नया इंस्टेंस स्थापित करने पर विचार करना उचित है।
2. एक नया इंस्टेंस सेट करें, यानी initdb चलाएँ। नए इंस्टेंस में पुराने इंस्टेंस की तुलना में अलग सेटिंग्स हो सकती हैं, उदाहरण के लिए लोकेल, वाल सेगमेंट आकार, या चेकसमिंग। (इस अवसर का उपयोग डेटा चेकसम चालू करने के लिए क्यों न करें?)
3. नया इंस्टेंस शुरू करने से पहले, आपको कुछ कॉन्फ़िगरेशन सेटिंग्स बदलने की आवश्यकता हो सकती है। यदि इंस्टेंस पुराने इंस्टेंस के समान होस्ट पर चलता है, तो आपको एक अलग पोर्ट नंबर सेट करना होगा। साथ ही, postgresql.conf . में आपके द्वारा किए गए किसी भी कस्टम परिवर्तन को जारी रखें आपके पुराने उदाहरण पर, जैसे कि मेमोरी सेटिंग्स, max_connections , आदि। इसी तरह, pg_hba.conf . बनाएं आपके पर्यावरण के लिए उपयुक्त सेटिंग्स। आप आमतौर पर pg_hba.conf . पर कॉपी करके शुरुआत कर सकते हैं पुराने उदाहरण से फ़ाइल। अगर आप एसएसएल का उपयोग करना चाहते हैं, तो इसे अभी सेट करें।
4. नया (खाली) इंस्टेंस शुरू करें और जांचें कि यह आपकी संतुष्टि के लिए काम करता है। यदि आप नए होस्ट पर नया इंस्टेंस सेट करते हैं, तो इस बिंदु पर जांचें कि आप नए होस्ट से पुराने डेटाबेस इंस्टेंस में डेटाबेस कनेक्शन (psql का उपयोग करके) बना सकते हैं। हमें बाद के चरणों में इसकी आवश्यकता होगी।
5. स्कीमा परिभाषाओं को pg_dumpall के साथ कॉपी करें। (या आप इसे प्रत्येक डेटाबेस के लिए अलग से pg_dump के साथ कर सकते हैं, लेकिन फिर भूमिकाओं जैसी वैश्विक वस्तुओं को न भूलें।)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
इस बिंदु के बाद कोई भी स्कीमा परिवर्तन माइग्रेट नहीं किया जाएगा। आपको उन्हें स्वयं प्रबंधित करना होगा। कई मामलों में, आप केवल दोनों मेजबानों पर बदलते डीडीएल को लागू कर सकते हैं, लेकिन अपग्रेड के दौरान टेबल संरचना को बदलने वाले कमांड चलाना शायद बहुत दूर की चुनौती है।
6. स्रोत उदाहरण में प्रत्येक डेटाबेस में, एक प्रकाशन बनाएं जो सभी तालिकाओं को कैप्चर करे:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
तार्किक प्रतिकृति प्रत्येक डेटाबेस में अलग से काम करती है, इसलिए इसे प्रत्येक डेटाबेस में दोहराया जाना चाहिए। दूसरी ओर, आपको सभी डेटाबेस को एक साथ अपग्रेड करने की आवश्यकता नहीं है, इसलिए आप एक बार में यह एक डेटाबेस कर सकते हैं या कुछ डेटाबेस को अपग्रेड भी नहीं कर सकते हैं।
7. लक्ष्य उदाहरण में प्रत्येक डेटाबेस में, एक सदस्यता बनाएं जो हाल ही में बनाए गए प्रकाशन की सदस्यता लेता है। सुनिश्चित करें कि स्रोत और लक्ष्य डेटाबेस का सही मिलान हो।
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
उपयुक्त के रूप में कनेक्शन पैरामीटर सेट करें।
8. अब आप तब तक प्रतीक्षा करें जब तक कि सदस्यता प्रारंभिक डेटा पर कॉपी न हो जाए और प्रकाशक के साथ पूरी तरह से पकड़ न जाए। आप सिस्टम कैटलॉग pg_subscription_rel में सदस्यता में प्रत्येक तालिका की प्रारंभिक समन्वयन स्थिति की जांच कर सकते हैं (r के लिए देखें =कॉलम में तैयार srsubstate ) प्रतिकृति की समग्र स्थिति की जाँच pg_stat_replication . में की जा सकती है भेजने के पक्ष में और pg_stat_subscription प्राप्त करने वाले पक्ष पर।
9. जैसा कि ऊपर उल्लेख किया गया है, अनुक्रम परिवर्तन दोहराए नहीं जाते हैं। इसके लिए एक संभावित समाधान pg_dump का उपयोग करके अनुक्रम मानों की प्रतिलिपि बनाना है। आप कुछ इस तरह का उपयोग करके वर्तमान अनुक्रम मानों का डंप प्राप्त कर सकते हैं:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(यह मानता है कि अनुक्रम नाम सभी *_seq . से मेल खाते हैं और कोई तालिका उस नाम से मेल नहीं खाती। अधिक जटिल मामलों में आप एक पूर्ण डंप बनाने और डंप की सामग्री की तालिका से अनुक्रम डेटा निकालने के मार्ग पर भी जा सकते हैं।)
चूंकि आप ऐसा करते-करते क्रम आगे बढ़ सकते हैं, शायद seq-data.sql को बंद कर दें फ़ाइल संख्याओं में थोड़ी सुस्ती जोड़ने के लिए।
फिर psql का उपयोग करके उस फ़ाइल को नए डेटाबेस में पुनर्स्थापित करें।
10. शोटाइम:एप्लिकेशन को नए इंस्टेंस पर स्विच करें। इसके लिए समय से पहले कुछ सोचने की जरूरत है। सबसे सरल परिदृश्य में, आप अपने एप्लिकेशन प्रोग्राम को रोकते हैं, कनेक्शन सेटिंग्स बदलते हैं, पुनरारंभ करते हैं। यदि आप कनेक्शन प्रॉक्सी का उपयोग करते हैं, तो आप वहां कनेक्शन पर स्विच कर सकते हैं। आप क्लाइंट एप्लिकेशन को एक-एक करके स्विच कर सकते हैं, शायद चीजों का थोड़ा परीक्षण करने के लिए या नए सिस्टम पर लोड को कम करने के लिए। यह तब तक काम करेगा जब तक कि पुराने सर्वर की ओर इशारा करने वाले एप्लिकेशन और नए सर्वर की ओर इशारा करने वाले परस्पर विरोधी लेखन नहीं करते हैं। (उस स्थिति में आप एक मल्टीमास्टर सिस्टम चला रहे होंगे, कम से कम थोड़े समय के लिए, और यह जटिलता का एक और क्रम है।)
11. जब अपग्रेड पूरा हो जाता है, तो आप प्रतिकृति सेटअप को फाड़ सकते हैं। नए इंस्टेंस पर प्रत्येक डेटाबेस में, रन करें
DROP SUBSCRIPTION s_upgrade;
यदि आपने पुराने उदाहरण को पहले ही बंद कर दिया है, तो यह विफल हो जाएगा क्योंकि यह प्रतिकृति स्लॉट को छोड़ने के लिए दूरस्थ सर्वर तक नहीं पहुंच पाएगा। इस स्थिति में कैसे आगे बढ़ें, इसके लिए DROP SUBSCRIPTION मैन पेज देखें।
आप प्रकाशनों को स्रोत उदाहरण पर भी छोड़ सकते हैं, लेकिन यह आवश्यक नहीं है क्योंकि प्रकाशन के पास कोई संसाधन नहीं है।
12. अंत में, पुराने उदाहरणों को हटा दें यदि आपको अब उनकी आवश्यकता नहीं है।
तार्किक प्रतिकृति का समर्थन नहीं करने वाली चीज़ों के समाधान पर कुछ अतिरिक्त टिप्पणियाँ। यदि आप बड़ी वस्तुओं का उपयोग कर रहे हैं, तो आप उन्हें pg_dump का उपयोग करके स्थानांतरित कर सकते हैं, निश्चित रूप से जब तक वे अपग्रेड प्रक्रिया के दौरान नहीं बदलते हैं। यह एक महत्वपूर्ण सीमा है, इसलिए यदि आप बड़ी वस्तुओं के भारी उपयोगकर्ता हैं, तो यह विधि आपके लिए नहीं हो सकती है। यदि आपका एप्लिकेशन नवीनीकरण प्रक्रिया के दौरान TRUNCATE जारी करता है, तो उन कार्रवाइयों को दोहराया नहीं जाएगा। अपग्रेड के समय ऐसा करने से रोकने के लिए शायद आप अपने एप्लिकेशन में बदलाव कर सकते हैं, या आप इसके बजाय DELETE को स्थानापन्न कर सकते हैं। PostgreSQL 11 TRUNCATE की प्रतिकृति का समर्थन करेगा, लेकिन यह तभी काम करेगा जब स्रोत और गंतव्य उदाहरण दोनों PostgreSQL 11 या नए हों।
कुछ समापन टिप्पणियाँ जो वास्तव में सभी अपग्रेड उपक्रमों पर लागू होती हैं:
- अनुप्रयोगों और सभी डेटाबेस क्लाइंट प्रोग्रामों को उत्पादन में डालने से पहले एक नए प्रमुख PostgreSQL संस्करण के विरुद्ध परीक्षण किया जाना चाहिए।
- इसके लिए, आपको उत्पादन वातावरण में इसे क्रियान्वित करने से पहले अपग्रेड प्रक्रिया का परीक्षण भी करना चाहिए।
- चीजें लिख लें या बेहतर स्क्रिप्ट और जितना हो सके स्वचालित करें।
- सुनिश्चित करें कि अपग्रेड प्रक्रिया के दौरान आपका बैकअप सेटअप, मॉनिटरिंग सिस्टम और किसी भी रखरखाव उपकरण और स्क्रिप्ट को उचित रूप से समायोजित किया गया है। आदर्श रूप से, ये स्विचओवर होने से पहले जगह पर और सत्यापित होने चाहिए।
इसे ध्यान में रखते हुए, शुभकामनाएँ और कृपया अपने अनुभव साझा करें।
