उत्पादन PostgreSQL डेटाबेस को प्रबंधित करना आसान बनाना

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

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

2. मास्टर और स्टैंडबाय के बीच कोई अंतर्निहित स्वचालित विफलता नहीं

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

3. कोई शून्य डाउनटाइम प्रमुख अपग्रेड नहीं

अपने PostgreSQL डेटाबेस को बिना डाउनटाइम के एक प्रमुख संस्करण से दूसरे में अपग्रेड करना संभव नहीं है। आपको अनिवार्य रूप से अपने सभी सर्वरों को बंद करना होगा और अपने डेटा को नए संस्करण में अपग्रेड करने के लिए pg_upgrad का उपयोग करना होगा। डाउनटाइम बड़ा नहीं है क्योंकि इसमें कोई डेटा कॉपी शामिल नहीं है, हालांकि, अभी भी डाउनटाइम है। अगर आप 24/7 ऑपरेशन चला रहे हैं, तो यह आपके लिए विकल्प नहीं हो सकता है।

तार्किक प्रतिकृति जारी होने के साथ, हमारे पास ऑनलाइन अपग्रेड के लिए एक वैकल्पिक विकल्प है।

1. नए संस्करण के साथ एकदम नया PostgreSQL मास्टर-स्टैंडबाय सेटअप बनाएं।
2. पुराने संस्करण से नए संस्करण में दोहराने के लिए तार्किक प्रतिकृति सेट करें।
3. एक बार जब आप तैयार हो जाएं, तो अपनी कनेक्शन स्ट्रिंग को पुराने सेटअप से नए सेटअप पर इंगित करने के लिए बदलें।

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

4. कोई इन-प्लेस वैक्यूम पूर्ण नहीं है

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

ध्यान दें:समुदाय ने पहले ही zheap स्टोरेज इंजन पर काम शुरू कर दिया है जो इस सीमा को पार कर जाता है।

यदि अन्य सुधार हैं जो आपके विचार से उपयोगी होंगे, तो बेझिझक एक टिप्पणी छोड़ दें।