इस श्रृंखला की अपनी पिछली पोस्ट में, हमने कनेक्शन पूलिंग के मामले पर चर्चा की और PgBouncer को पेश किया। इस पोस्ट में, हम इसके सबसे लोकप्रिय विकल्प - Pgpool-II पर चर्चा करेंगे।
Pgpool-II PostgreSQL मिडलवेयर का स्विस आर्मी नाइफ है। यह उच्च-उपलब्धता का समर्थन करता है, स्वचालित भार संतुलन प्रदान करता है, और स्वामी और दासों के बीच भार को संतुलित करने की बुद्धि रखता है, इसलिए लिखने का भार हमेशा स्वामी पर निर्देशित होता है, जबकि रीड लोड दासों को निर्देशित किया जाता है। Pgpool-II तार्किक प्रतिकृति भी प्रदान करता है। जबकि PostgreSQL सर्वर साइड पर इनबिल्ट प्रतिकृति विकल्पों में सुधार के रूप में इसका उपयोग और महत्व कम हो गया है, यह अभी भी PostgreSQL के पुराने संस्करणों के लिए एक मूल्यवान विकल्प बना हुआ है। इन सबसे ऊपर, यह कनेक्शन पूलिंग भी प्रदान करता है!
एक नज़र में | ||||||
---|---|---|---|---|---|---|
|
पगपूल-II सेट अप करना
Pgpool-II बायनेरिज़ को Pgpool-II के रिपॉजिटरी के माध्यम से वितरित किया जाता है - आप इस सहायता दस्तावेज़ में इंस्टॉलेशन के बारे में अधिक पढ़ सकते हैं। एक बार स्थापित होने के बाद, हमें अपनी इच्छित सेवाओं को सक्षम करने और PostgreSQL सर्वर से कनेक्ट करने के लिए Pgpool-II को कॉन्फ़िगर करना होगा। आप इसके बारे में यहाँ और अधिक पढ़ सकते हैं।
न्यूनतम पूलिंग सेटअप प्राप्त करने के लिए, आपको निम्नलिखित प्रदान करना होगा:
- उपयोगकर्ता (उपयोगकर्ताओं) का उपयोगकर्ता नाम और md5 एन्क्रिप्टेड पासवर्ड जो Pgpool-II से कनेक्ट होगा - इसे एक अलग फ़ाइल में परिभाषित किया जाना चाहिए, जिसे आसानी से pg_md5 उपयोग का उपयोग करके उत्पन्न किया जा सकता है।
- आने वाले कनेक्शनों को सुनने के लिए इंटरफ़ेस/आईपी-पते और पोर्ट नंबर - इसे कॉन्फ़िगरेशन फ़ाइल में परिभाषित किया जाना चाहिए।
- बैकएंड सर्वर का होस्टनाम [एक से अधिक सर्वर केवल तभी निर्दिष्ट किए जाते हैं जब हम प्रतिकृति और/या लोड संतुलन का उपयोग करना चाहते हैं]।
- वे सेवाएं जिन्हें आप सक्षम करना चाहते हैं। डिफ़ॉल्ट रूप से, कनेक्शन पूलिंग चालू है, और बायनेरिज़ के साथ स्थापित कॉन्फ़िगरेशन फ़ाइल में अन्य सेवाएँ बंद हैं।
और बस इतना ही - हम जाने के लिए तैयार हैं! जबकि Pgpool-II के साथ उपलब्ध कॉन्फ़िगरेशन पहली नज़र में अधिक कठिन हो सकता है, Pgpool-II के पीछे के लोगों ने वास्तव में हमारे लिए इसे आसान बना दिया है!
यह कैसे काम करता है
Pgpool-II में PgBouncer की तुलना में अधिक शामिल आर्किटेक्चर है, ताकि सभी सुविधाओं का समर्थन किया जा सके। हालांकि, इस खंड में, हम खुद को यह बताने तक सीमित रखेंगे कि कनेक्शन पूलिंग कैसे काम करती है।
Pgpool-II पैरेंट प्रोसेस 32 चाइल्ड प्रोसेस को डिफॉल्ट रूप से फोर्क करता है - ये कनेक्शन के लिए उपलब्ध हैं। आर्किटेक्चर PostgreSQL सर्वर के समान है:एक प्रक्रिया =एक कनेक्शन। यह 'पीसीपी प्रक्रिया' का भी उपयोग करता है जिसका उपयोग प्रशासनिक कार्यों के लिए और इस पद के दायरे से बाहर किया जाता है। 32 बच्चे अब कनेक्शन लेने के लिए तैयार हैं। PgBouncer की तरह, ये भी एक PostgreSQL सर्वर का अनुकरण करते हैं - क्लाइंट ठीक उसी कनेक्शन स्ट्रिंग से जुड़ सकते हैं जैसे वे एक सामान्य PostgreSQL सर्वर से करते हैं।
कर्नेल आने वाले कनेक्शनों को श्रोताओं के रूप में पंजीकृत चाइल्ड प्रक्रियाओं में से एक के लिए निर्देशित करता है। न तो मुख्य Pgpool-II प्रक्रिया और न ही अंतिम-उपयोगकर्ताओं का इस पर कोई नियंत्रण होता है कि कौन सी चाइल्ड प्रक्रिया आने वाले अनुरोध का जवाब देती है। कोई भी बेकार बच्चा अनुरोध उठा सकता है। यदि कोई निष्क्रिय बच्चे नहीं मिलते हैं, तो कनेक्शन अनुरोध कर्नेल की तरफ कतारबद्ध हो जाएगा - इससे pgbench जैसे एप्लिकेशन हैंग हो सकते हैं, क्लाइंट कनेक्शन की प्रतीक्षा कर रहे हैं।
एक बार निष्क्रिय Pgpool-II बच्चे को एक कनेक्शन अनुरोध प्राप्त हो जाने पर, यह:
- इसकी पासवर्ड फ़ाइल में उपयोगकर्ता नाम की जांच करता है। यदि नहीं मिला, तो यह कनेक्शन को अस्वीकार कर देता है।
- यदि उपयोगकर्ता नाम मिल जाता है, तो यह इस फ़ाइल में संग्रहीत md5 हैश के विरुद्ध दिए गए पासवर्ड की जांच करता है।
- एक बार प्रमाणीकरण सफल हो जाने पर, यह जांचता है कि क्या इस डेटाबेस+उपयोगकर्ता संयोजन के लिए पहले से कैश्ड कनेक्शन है या नहीं।
- यदि ऐसा होता है, तो यह क्लाइंट को कनेक्शन लौटा देता है। यदि ऐसा नहीं होता है, तो यह एक नया कनेक्शन खोलता है।
- क्लाइंट के डिस्कनेक्ट होने का इंतजार करते हुए सभी अनुरोध और प्रतिक्रियाएं Pgpool-II से होकर गुजरती हैं।
- क्लाइंट के डिस्कनेक्ट हो जाने पर, Pgpool-II को यह तय करना होगा कि कनेक्शन को कैश करना है या नहीं:
- अगर इसमें खाली स्लॉट है, तो वह इसे कैश कर लेता है।
- यदि इसमें खाली स्लॉट नहीं है (अर्थात, इस कनेक्शन को कैशिंग करने की अनुमति अधिकतम_पूल_साइज़ से अधिक होगी), तो यह आंतरिक एल्गोरिथम के आधार पर निर्णय करेगा।
- यदि यह कनेक्शन को कैश करने का निर्णय लेता है, तो यह सभी सत्र विवरणों को साफ करने और इसे किसी भिन्न क्लाइंट द्वारा पुन:उपयोग के लिए सुरक्षित बनाने के लिए पूर्व-कॉन्फ़िगर रीसेट क्वेरी चलाएगा।
- अब चाइल्ड प्रोसेस अधिक कनेक्शन लेने के लिए स्वतंत्र है।
|
पगपूल-II क्या नहीं करता है?
दुर्भाग्य से, केवल कनेक्शन पूलिंग पर ध्यान केंद्रित करने वालों के लिए, Pgpool-II जो बहुत अच्छा नहीं करता है, वह है कनेक्शन पूलिंग, विशेष रूप से ग्राहकों की एक छोटी संख्या के लिए। चूंकि प्रत्येक चाइल्ड प्रोसेस का अपना पूल होता है, और यह नियंत्रित करने का कोई तरीका नहीं है कि कौन सा क्लाइंट किस चाइल्ड प्रोसेस से कनेक्ट होता है, कनेक्शन का पुन:उपयोग करने की बात आने पर बहुत कुछ भाग्य पर छोड़ दिया जाता है।
जैसा कि आप देख सकते हैं, Pgpool और PgBouncer की ताकत अलग-अलग है - श्रृंखला के हमारे अंतिम पोस्ट में, हम एक आमने-सामने परीक्षण करेंगे , और सुविधा तुलना! बने रहें!
PostgreSQL कनेक्शन पूलिंग सीरीज
|
---|