PostgreSQL अपग्रेड को खोलना

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

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

प्वाइंट रिलीज

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

हमेशा नवीनतम बिंदु रिलीज पर बने रहना बहुत बुद्धिमानी है, इसलिए आप किसी ज्ञात (और संभावित रूप से तय) बग पर ठोकर नहीं खाते हैं। इसका मतलब है कि एक बार नवीनतम संस्करण समाप्त हो जाने के बाद, उन्नयन के लिए जल्द से जल्द समय निर्धारित करें।

प्रमुख रिलीज़ अपग्रेड

इस तरह के जटिल कार्य करते समय, अंतिम परिणाम प्राप्त करने के लिए सभी संभावित विकल्पों पर विचार करना अच्छा होता है।

प्रमुख रिलीज़ अपग्रेड के लिए, आप तीन संभावित पथ अपना सकते हैं:

• तार्किक डंप से पुनर्स्थापित करना अपग्रेड करें
• शारीरिक उन्नयन
• ऑन-लाइन अपग्रेड

मुझे प्रत्येक के बारे में विस्तार से बताएं:

1) तार्किक डंप से पुनर्स्थापित करना अपग्रेड करें

यह आपके क्लस्टर की डेटा संरचना को अपग्रेड करने के सभी संभावित तरीकों में सबसे आसान तरीका है।

इसे संक्षिप्त करने के लिए, यहां प्रक्रिया को पुराने संस्करण से pg_dump का उपयोग करके एक तार्किक डंप की आवश्यकता है, और नए स्थापित संस्करण के साथ बनाए गए एक साफ क्लस्टर पर pg_restore।

इस पथ का उपयोग करने के पक्ष में प्रमुख बिंदु हैं:

• यह सबसे अधिक परीक्षण किया गया है
• संगतता 7.0 संस्करणों पर वापस चली जाती है ताकि आप अंततः 7.x से हाल ही में जारी किसी एक में अपग्रेड कर सकें

जिन कारणों से आपको इस विकल्प का उपयोग करने से बचना चाहिए:

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

कई सीपीयू कोर वाले सर्वर पर, निर्देशिका प्रारूप का उपयोग करके समानांतर में pg_dump चलाना संभव है। एक बार यह समाप्त हो जाने के बाद, pg_dump और pg_restore दोनों में -j स्विच का उपयोग करके, समानांतर में भी पुनर्स्थापित करें। लेकिन जब तक पूरा डंप समाप्त नहीं हो जाता, तब तक आप पुनर्स्थापना प्रक्रिया शुरू नहीं कर सकते।

2) भौतिक उन्नयन

इस प्रकार के उन्नयन संस्करण 9.0 के बाद से उपलब्ध हैं, जो 8.3 से पुराने संस्करणों से इन-प्लेस अपग्रेड करने के लिए उपलब्ध हैं। उन्हें "इन-प्लेस" कहा जाता है क्योंकि वे एक ही सर्वर पर और अधिमानतः एक ही डेटा निर्देशिका पर किए जाते हैं।

इस प्रकार के उन्नयन के लाभ:

• क्लस्टर की दूसरी कॉपी के लिए आपको जगह की जरूरत नहीं है।
• pg_dump का उपयोग करने की तुलना में डाउनटाइम बहुत कम है।

इसके कुछ नुकसान हैं:

• एक बार जब आप PostgreSQL का नया संस्करण शुरू कर देते हैं तो पुराने संस्करण पर वापस नहीं जाता है (क्लस्टर वहां से केवल नए संस्करण के साथ काम करेगा)।
• आंकड़े अपग्रेड के बाद शून्य हो जाते हैं, इसलिए PostgreSQL का नया संस्करण शुरू करने के ठीक बाद एक क्लस्टर व्यापक विश्लेषण निष्पादित किया जाना है।
• पिछले वर्षों में pg_upgrad के संबंध में कई बग पाए गए हैं, जो कुछ डेटाबेस व्यवस्थापकों को अपग्रेड करने के लिए इस पद्धति का उपयोग करने से हिचकते हैं।
• किसी प्रमुख रिलीज़ को छोड़ते समय कुछ लोगों को समस्या हुई है, उदाहरण के लिए संस्करण 9.2 से संस्करण 9.4 में जाना।
• बड़े कैटलॉग के साथ यह खराब प्रदर्शन करेगा (कई डेटाबेस वाले क्लस्टर, या हजारों ऑब्जेक्ट वाले डेटाबेस)।

आप -लिंक विकल्प के बिना भी pg_upgrad चला सकते हैं (इस स्थिति में pg_upgrad आपके क्लस्टर की डिस्क पर दूसरी प्रति उत्पन्न करेगा) ताकि आप पुराने संस्करण पर वापस जा सकें। लेकिन आप ऊपर सूचीबद्ध दोनों लाभों को खो देंगे।

3) ऑनलाइन अपग्रेड

इस पद्धति का पालन करने की प्रक्रिया इस प्रकार होगी:

1. दोनों संस्करणों को स्थापित करें ताकि आप उन्हें समानांतर में काम कर सकें। यह एक ही सर्वर पर या दो भौतिक सर्वरों का उपयोग करके किया जा सकता है।
2. प्रारंभिक प्रतिलिपि बनाएं, और स्रोत नोड पर प्रतिलिपि प्रारंभ करने के क्षण से परिवर्तनों को दोहराएं (यह प्रारंभिक pg_dump के समान होगा)।
3. जब तक अंतराल शून्य के करीब न हो, तब तक तार्किक रूप से परिवर्तनों को दोहराते रहें।
4. नए सर्वर से कनेक्ट करने के लिए एप्लिकेशन सर्वर से कनेक्शन जानकारी को फिर से इंगित करें।

इस प्रकार का अपग्रेड उपलब्ध है क्योंकि पहले ट्रिगर आधारित प्रतिकृति समाधान आसपास थे। दूसरे शब्दों में, चूंकि स्लोनी-मैं आसपास था।

ट्रिगर आधारित प्रतिकृति समाधान इस बात की परवाह नहीं करते कि आपके पास एक तरफ या दूसरी तरफ कौन सा संस्करण है, क्योंकि यह समर्थित SQL कमांड का उपयोग करके परिवर्तनों की प्रतिलिपि बनाता है।

अनुशंसित ट्रिगर आधारित प्रतिकृति उपकरण, जिस क्रम में वे दिखाई देते हैं, वे हैं:

1. स्काईटूल:PgQ + londiste
2. स्लोनी-I

उन्नयन के लिए यह पसंदीदा तरीका होना चाहिए। आइए देखें इस पद्धति का उपयोग करने के फायदे:

• शून्य डाउनटाइम!
• नए हार्डवेयर में अपग्रेड करने के लिए भी बढ़िया।
• नए संस्करण के साथ क्लस्टर का ऑनलाइन परीक्षण (केवल-पढ़ने के लिए प्रश्न, या आप विरोध के साथ समाप्त हो सकते हैं)।
• सभी टेबल और इंडेक्स ब्लोट्स को काफी कम कर देता है।

कुछ नुकसान हैं:

• इसे डबल स्टोरेज स्पेस की जरूरत है, क्योंकि इसमें आपके डेटा की दूसरी कॉपी स्टोर करनी होती है।
• चूंकि यह ट्रिगर्स पर आधारित है, सिस्टम को प्रत्येक परिवर्तन को दो बार लिखना होता है, जिसका अर्थ है कि मेरे पास सोर्स सर्वर (क्लस्टर का पुराना संस्करण) पर अधिक डिस्क I/O होगा।
• सभी तालिकाओं में प्राथमिक कुंजी होनी चाहिए, इसलिए प्रतिकृति उपकरण अद्यतन या हटाए गए टुपल्स को अलग-अलग कर सकता है
• यह कैटलॉग तालिकाओं को दोहराता नहीं है, इसलिए यह बड़ी वस्तुओं को नहीं दोहराएगा।
• बुनियादी उपयोग में स्कीमा परिवर्तन शामिल नहीं हैं। यह किया जा सकता है, लेकिन पारदर्शी रूप से नहीं।

pglogic के साथ एक नई सीमा

PostgreSQL 9.4 के बाद से हमारे पास लेन-देन लॉग का तार्किक डिकोडिंग है। इसका मतलब है कि अब हम वाल से लेनदेन को डीकोड कर सकते हैं और आउटपुट में हेरफेर कर सकते हैं।

प्रतिकृति क्षेत्र में संभावनाओं की एक पूरी नई दुनिया दिखाई दी। तार्किक प्रतिकृति को पूरा करने के लिए ट्रिगर अब आवश्यक नहीं हैं!

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

तो, इस सबका क्या मतलब है?

ठीक है, यदि आप PostgreSQL के संस्करण 9.4 या 9.5 पर हैं और आप 9.6 में अपग्रेड करना चाहते हैं, तो आप ऊपर दिए गए विवरण की तरह एक ऑनलाइन अपग्रेड कर सकते हैं, लेकिन ट्रिगर आधारित प्रतिकृति समाधानों में से एक के बजाय pglogic का उपयोग कर सकते हैं।

मैं विवरण में आगे नहीं जाऊंगा क्योंकि इस विशेष विषय पर अन्य ब्लॉग हैं, जैसे कि पेट्र जेलिनेक द्वारा लिखित यह:PostgreSQL 9.6beta1 के लिए PGLogical 1.1 पैकेज

निष्कर्ष

आपके डेटाबेस की स्कीमा, डेटा आकार, संभव डाउन टाइम विंडो, वर्तमान PostgreSQL स्थापना के संस्करण के आधार पर आप एक विकल्प को दूसरे पर चुन सकते हैं या जो भी सबसे अच्छा फिट बैठता है।

• यदि आपका डेटाबेस छोटा है और एक उपयुक्त रखरखाव विंडो है जिसका आप उपयोग कर सकते हैं, तो आप pg_dump और pg_restore चलाने का विकल्प चुन सकते हैं। डेटा सेट के आकार के आधार पर एक बिंदु है जहां विकल्प अब संभव नहीं है।
• यदि आपके पास एक बड़ा डेटाबेस (कई सैकड़ों GB, या यहां तक ​​कि TB का डेटा) है, तो आपको pg_upgrad के साथ इन-प्लेस अपग्रेड या ऑनलाइन अपग्रेड जैसे अन्य विकल्पों की तलाश करनी होगी।
  • यदि आप संस्करण 8.3 या उच्चतर संस्करण से किसी 9.x संस्करण में अपग्रेड कर रहे हैं तो आप pg_upgrad का उपयोग कर सकते हैं।
  • 8.3 से पुराने संस्करणों के लिए, आपको लोंडिस्ट या स्लोनी जैसे तार्किक प्रतिकृति समाधानों में से एक को चुनना होगा।
  • यदि 9.4 या 9.5 डेटाबेस पर आप pglogic का उपयोग करना बेहतर समझते हैं।

हमेशा याद रखें कि तार्किक प्रतिकृति के लिए तालिकाओं में एक प्राथमिक कुंजी होनी चाहिए।

pglogic के साथ वह नियम इतना सख्त नहीं है:आप केवल-सम्मिलित तालिकाओं को दोहरा सकते हैं। लेकिन अपडेट करने और हटाने के लिए, टेबल पर प्राथमिक कुंजी या प्रतिकृति पहचान होना अभी भी अनिवार्य है।

यदि आपको अपने PostgreSQL डेटाबेस को अपग्रेड करने के लिए सहायता की आवश्यकता है, तो आप
द्वितीय चतुर्थांश अपग्रेड सेवाओं की जांच कर सकते हैं।