PostgreSQL के लिए pgBouncer का उपयोग करने के लिए एक गाइड

PostgreSQL को पढ़ना शुरू करते समय, आप लाइन देखते हैं:"PostgreSQL सर्वर क्लाइंट से कई समवर्ती कनेक्शनों को संभाल सकता है। इसे प्राप्त करने के लिए, यह प्रत्येक कनेक्शन के लिए एक नई प्रक्रिया ("कांटे") शुरू करता है। उस बिंदु से, क्लाइंट और नई सर्वर प्रक्रिया मूल पोस्टग्रेज प्रक्रिया द्वारा हस्तक्षेप किए बिना संवाद करती है। इस प्रकार, मास्टर सर्वर प्रक्रिया हमेशा चल रही है, क्लाइंट कनेक्शन की प्रतीक्षा कर रही है, जबकि क्लाइंट और संबंधित सर्वर प्रक्रियाएं आती हैं और जाती हैं। "

कमाल की सोच। और फिर भी इसका मतलब है कि हर नया कनेक्शन एक नई प्रक्रिया को स्पिन करता है, रैम को जमा करता है और संभवतः कई सत्रों के साथ बहुत भारी हो जाता है। समस्याओं से बचने के लिए, पोस्टग्रेज में डिफ़ॉल्ट 100 कनेक्शन के साथ max_connections सेटिंग है। बेशक आप इसे बढ़ा सकते हैं, लेकिन इस तरह की कार्रवाई को फिर से शुरू करने की आवश्यकता होगी (pg_settings.context 'पोस्टमास्टर' है):

t=# select name,setting,short_desc,context from pg_settings where name = 'max_connections';
-[ RECORD 1 ]--------------------------------------------------
name       | max_connections
setting    | 100
short_desc | Sets the maximum number of concurrent connections.
context    | postmaster

कुछ रोमांचक रीडिंग PgBouncer उपयोग उछलने का क्या मतलब है? स्टैक ओवरफ्लो पर 'pgbouncer' वाली पोस्ट

और बढ़ने के बाद भी - किसी बिंदु पर आपको अधिक कनेक्शन की आवश्यकता हो सकती है (निश्चित रूप से हमेशा की तरह चल रहे उत्पादों पर)। इसे बढ़ाना इतना असहज क्यों है? क्योंकि अगर यह आरामदेह होता, तो आप शायद तब तक संख्या में अनियंत्रित सहज वृद्धि के साथ समाप्त हो जाते जब तक कि क्लस्टर पिछड़ना शुरू नहीं हो जाता। मतलब पुराने कनेक्शन धीमे होते हैं - इसलिए उनमें अधिक समय लगता है, इसलिए आपको अधिक से अधिक नए कनेक्शन की आवश्यकता होती है। इस तरह के संभावित हिमस्खलन से बचने और कुछ लचीलापन जोड़ने के लिए, हमारे पास superuser_reserved_connections हैं - max_connections समाप्त होने पर SU के साथ समस्याओं को जोड़ने और ठीक करने में सक्षम होने के लिए। और हम स्पष्ट रूप से कुछ कनेक्शन पूलर की आवश्यकता देखते हैं। चूंकि हम चाहते हैं कि नए कनेक्शन उम्मीदवार अपवाद के साथ विफल होने के बजाय कतार में प्रतीक्षा करें FATAL:क्षमा करें, पहले से ही बहुत सारे ग्राहक हैं और पोस्टमास्टर को जोखिम में नहीं डाल रहे हैं।

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

तो आइए हम करीब से देखें कि यह क्या कर सकता है और आप इसका उपयोग कैसे करते हैं। अपने सेटअप में मैं डिफ़ॉल्ट पूल_मोड =लेनदेन ([pgbouncer] अनुभाग) का उपयोग करता हूं जो एक बहुत लोकप्रिय विकल्प है। इस तरह हम न केवल max_connections से अधिक कनेक्शनों को कतारबद्ध करते हैं, बल्कि पिछले कनेक्शन के बंद होने की प्रतीक्षा किए बिना सत्रों का पुन:उपयोग करते हैं:

[databases]
mon = host=1.1.1.1 port=5432 dbname=mon
mons = host=1.1.1.1 port=5432 dbname=mon pool_mode = session pool_size=2 max_db_connections=2
monst = host=1.1.1.1 port=5432 dbname=mon pool_mode = statement
[pgbouncer]
listen_addr = 1.1.1.1
listen_port = 6432
unix_socket_dir = /tmp
auth_file = /pg/pgbouncer/bnc_users.txt
auth_type = hba
auth_hba_file = /pg/pgbouncer/bnc_hba.conf
admin_users = root vao
pool_mode = transaction
server_reset_query = RESET ALL; --DEALLOCATE ALL; /* custom */
ignore_startup_parameters = extra_float_digits
application_name_add_host = 1
max_client_conn = 10000
autodb_idle_timeout = 3600
default_pool_size = 100
max_db_connections = 100
max_user_connections = 100
#server_reset_query_always = 1 #uncomment if you want older global behaviour

सबसे लोकप्रिय सेटिंग्स और युक्तियों और युक्तियों का संक्षिप्त अवलोकन:

server_reset_query बहुत आसान और महत्वपूर्ण है। सत्र पूलिंग मोड में, यह पिछले सत्र "कलाकृतियों" को "वाइप" करता है। अन्यथा आपको तैयार किए गए कथनों के लिए समान नामों, अगले सत्रों को प्रभावित करने वाली सत्र सेटिंग्स आदि में समस्या होगी। डिफ़ॉल्ट सभी को छोड़ दें, जो सभी सत्र राज्यों को "रीसेट" करता है। फिर भी आप अधिक परिष्कृत मान चुन सकते हैं, जैसे, सभी को रीसेट करें; सभी का आवंटन करें; केवल SET SESSION और तैयार किए गए बयानों को भूलने के लिए, TEMP टेबल और योजनाओं को "साझा" रखते हुए। या इसके विपरीत - आप किसी भी सत्र से तैयार बयान "वैश्विक" बनाना चाह सकते हैं। ऐसा विन्यास जोखिम भरा होने के बावजूद करने योग्य है। आपको pgbouncer को सभी के लिए सत्र का पुन:उपयोग करना होगा (इस प्रकार या तो बहुत छोटा पूल आकार बनाना या सत्रों को हिमस्खलन करना), जो पूरी तरह विश्वसनीय नहीं है। वैसे भी - यह एक उपयोगी क्षमता है। विशेष रूप से उन सेटअपों में जहां आप क्लाइंट सत्र को अंततः (तुरंत नहीं) कॉन्फ़िगर किए गए पूल सत्र सेटिंग्स में बदलना चाहते हैं। यहां बहुत महत्वपूर्ण बिंदु सत्र पूल मोड है। 1.6 से पहले इस सेटिंग ने अन्य पूल मोड को भी प्रभावित किया था, इसलिए यदि आप इस पर भरोसा करते हैं, तो आपको नई सेटिंग server_reset_query_always =1 का उपयोग करने की आवश्यकता है। शायद किसी बिंदु पर लोग चाहते हैं कि server_reset_query प्रति डीबी/उपयोगकर्ता जोड़ी को और भी अधिक लचीला और कॉन्फ़िगर करने योग्य हो ( और इसके बजाय client_reset_query)। लेकिन वर्तमान लेखन के अनुसार, मार्च 2018, यह एक विकल्प नहीं है। इस सेटिंग को डिफ़ॉल्ट रूप से केवल सत्र मोड के लिए मान्य बनाने के पीछे का विचार था - यदि आप लेन-देन या विवरण स्तर पर कनेक्शन साझा करते हैं - तो आप सत्र सेटिंग पर बिल्कुल भी भरोसा नहीं कर सकते।
Auth_type =hba. 1.7 से पहले, pgbouncer के साथ बड़ी समस्या मेजबान आधारित प्रमाणीकरण की अनुपस्थिति थी - "फ़ायरवॉल पोस्टग्रेज"। बेशक आपके पास अभी भी क्लस्टर कनेक्शन को पोस्टग्रेज करने के लिए था, लेकिन pgbouncer किसी भी स्रोत के लिए "खुला" था। अब हम कनेक्शन नेटवर्क के आधार पर होस्ट/डीबी/उपयोगकर्ता के लिए कनेक्शन सीमित करने के लिए उसी hba.conf का उपयोग कर सकते हैं।
Connect_query प्रत्येक क्लाइंट "कनेक्शन" पर pgbouncer पर नहीं किया जाता है, बल्कि जब pgbouncer पोस्टग्रेज इंस्टेंस से कनेक्ट होता है। इस प्रकार आप इसका उपयोग "डिफ़ॉल्ट" सेटिंग्स को सेट करने या ओवरराइड करने के लिए नहीं कर सकते। सत्र मोड में, अन्य सत्र एक-दूसरे को प्रभावित नहीं करते हैं और डिस्कनेक्ट होने पर, रीसेट क्वेरी सभी को छोड़ देती है - इसलिए आपको इसके साथ खिलवाड़ करने की आवश्यकता नहीं है। लेन-देन पूलिंग मोड में, आप अन्य सत्रों द्वारा गलत तरीके से सेट की गई सेटिंग्स को ओवरराइड करने के लिए इसका उपयोग करने की उम्मीद करेंगे, लेकिन यह काम नहीं करेगा, अफसोस। उदा. आप लेन-देन मोड में "सत्रों" के बीच तैयार विवरण साझा करना चाहते हैं, इसलिए आप कुछ इस तरह सेट करते हैं
```
trns = dbname=mon pool_mode = transaction connect_query = 'do $$ begin raise warning $w$%$w$, $b$new connection$b$; end; $$; prepare s(int) as select $1;'
```
और वास्तव में - प्रत्येक नया ग्राहक तैयार बयान देखता है (जब तक कि आपने server_reset_query_always को चालू नहीं छोड़ा है, इसलिए pgbouncer इसे प्रतिबद्ध होने पर छोड़ देता है)। लेकिन अगर कुछ क्लाइंट DISCARD s चलाता है; अपने सत्र में, यह इस कनेक्शन पर सभी ग्राहकों को प्रभावित करता है और इससे जुड़ने वाले नए ग्राहक अब तैयार किए गए बयान नहीं देखेंगे। लेकिन अगर आप pgbouncer से आने वाले पोस्टग्रेज कनेक्शन के लिए कुछ प्रारंभिक सेटिंग करना चाहते हैं, तो यह वह जगह है।
application_name_add_host 1.6 में जोड़ा गया था, इसकी समान सीमा है। यह क्लाइंट आईपी को application_name पर "डालता" है, ताकि आप आसानी से अपना खराब क्वेरी स्रोत प्राप्त कर सकें, लेकिन सरल सेट application_name द्वारा आसानी से ओवरराइड किया जाता है 'मैं नहीं था'; फिर भी आप विचारों का उपयोग करके इसे "ठीक" कर सकते हैं - विचार प्राप्त करने के लिए इस पोस्ट का अनुसरण करें या इन छोटे निर्देशों का भी उपयोग करें। मूल रूप से विचार यह है कि ग्राहकों को दिखाएं; क्लाइंट आईपी दिखाएगा, इसलिए आप इसे pg_stat_activity से प्रत्येक चयन पर सीधे pgbouncer डेटाबेस से क्वेरी कर सकते हैं ताकि यह जांचा जा सके कि यह रीसेट है या नहीं। लेकिन निश्चित रूप से एक साधारण सेटिंग का उपयोग करना बहुत आसान और आसान है। हालांकि यह परिणाम की गारंटी नहीं देता...
पूल_मोड को डिफ़ॉल्ट, प्रति डेटाबेस और प्रति उपयोगकर्ता दोनों के रूप में निर्दिष्ट किया जा सकता है - जिससे यह बहुत लचीला हो जाता है। मिक्सिंग मोड pgbouncer को पूलिंग के लिए बेहद प्रभावी बनाता है। यह एक शक्तिशाली विशेषता है, लेकिन इसका उपयोग करते समय सावधान रहना होगा। अक्सर उपयोगकर्ता इसका उपयोग परिणामों को समझे बिना प्रति लेनदेन/प्रति सत्र/प्रति उपयोगकर्ता/प्रति डेटाबेस/वैश्विक सेटिंग्स के बिल्कुल परमाणु मिश्रणों के लिए एक ही उपयोगकर्ता या डेटाबेस के लिए अलग-अलग तरीके से काम कर रहे हैं, pgbouncer के साथ अलग-अलग पूलिंग मोड के कारण। यह माचिस की डिब्बी है जिसे आप पर्यवेक्षण के बिना बच्चों को नहीं देते हैं। इसके अलावा कई अन्य विकल्प डिफ़ॉल्ट और प्रति डीबी और प्रति उपयोगकर्ता के लिए विन्यास योग्य हैं।
कृपया इसे शाब्दिक रूप से न लें, लेकिन आप SET और ALTER के साथ ini के विभिन्न वर्गों की "तुलना" कर सकते हैं:SET LOCAL लेन-देन को प्रभावित करता है और इसका उपयोग करना अच्छा होता है जब poll_mode=transaction , SET SESSION सत्रों को प्रभावित करता है और जब poll_mode=session उपयोग के लिए सुरक्षित होता है , ALTER USER SET भूमिकाओं को प्रभावित करता है और [उपयोगकर्ताओं] अनुभाग के pgbouncer.ini भाग के साथ हस्तक्षेप करेगा, ALTER DATABASE SET डेटाबेस को प्रभावित करता है और खंड [डेटाबेस] के pgbouncer.ini भाग के साथ हस्तक्षेप करेगा, सिस्टम सेट बदलें या postgres.conf का संपादन वैश्विक रूप से डिफ़ॉल्ट को प्रभावित करता है और इसकी तुलना pgbouncer.ini के डिफ़ॉल्ट सेक्शन से की जा सकती है।
एक बार फिर - पूल मोड का जिम्मेदारी से उपयोग करें। तैयार किए गए स्टेटमेंट या सेशन वाइड सेटिंग्स ट्रांजेक्शन पूलिंग मोड में एक गड़बड़ होगी। SQL लेनदेन के समान ही स्टेटमेंट पूलिंग मोड में कोई मतलब नहीं है। उपयुक्त कनेक्शन के लिए उपयुक्त पूलिंग मोड चुनें। एक अच्छा अभ्यास इस विचार के साथ भूमिकाएँ बनाना है कि:
- कुछ केवल तेजी से चयन चलाएंगे, इस प्रकार एक सत्र को बिना लेन-देन के सौ समवर्ती छोटे महत्वपूर्ण चयनों के लिए साझा कर सकते हैं।
- कुछ भूमिका सदस्य सत्र स्तरीय संगामिति के लिए सुरक्षित हैं, और हमेशा लेनदेन का उपयोग करते हैं। इस प्रकार वे सैकड़ों समवर्ती लेनदेन के लिए कई सत्रों को सुरक्षित रूप से साझा कर सकते हैं।
- कुछ भूमिकाएं अपने सत्र को दूसरों के साथ साझा करने के लिए बहुत जटिल हैं। इसलिए जब आप सभी "स्लॉट" पहले ही ले लिए जाते हैं तो कनेक्शन में त्रुटियों से बचने के लिए आप उनके लिए सत्र पूलिंग मोड का उपयोग करते हैं।
HAProxy या किसी अन्य लोड बैलेंसर के बजाय इसका उपयोग न करें। इस तथ्य के बावजूद कि pgbouncer में कई विन्यास योग्य विशेषताएं हैं जो एक लोड बैलेंसर पते को संबोधित करती हैं, जैसे dns_max_ttl और आप इसके लिए एक DNS कॉन्फ़िगरेशन सेट कर सकते हैं, अधिकांश उत्पाद वातावरण HAProxy या HA के लिए कुछ अन्य लोड बैलेंसर का उपयोग करते हैं। ऐसा इसलिए है क्योंकि HAProxy वास्तव में राउंड रॉबिन फैशन में लाइव सर्वर पर लोड संतुलन में अच्छा है, pgbouncer से बेहतर है। हालांकि कनेक्शन पूलिंग को पोस्टग्रेज करने के लिए pgbouncer बेहतर है, लेकिन एक छोटे डेमॉन का उपयोग करना बेहतर हो सकता है जो दो कार्यों को करने वाले बड़े डेमॉन के बजाय पूरी तरह से एक कार्य करता है, लेकिन इससे भी बदतर।
कॉन्फ़िगरेशन परिवर्तन मुश्किल हो सकते हैं। pgbouncer.ini में कुछ परिवर्तनों के लिए पुनरारंभ (सुनें_पोर्ट और ऐसे) की आवश्यकता होती है, जबकि अन्य जैसे admin_users को पुनः लोड या SIGHUP की आवश्यकता होती है। auth_hba_file के अंदर परिवर्तन को पुनः लोड करने की आवश्यकता होती है, जबकि auth_file में परिवर्तन नहीं होते हैं।

उपरोक्त सेटिंग्स का अत्यंत संक्षिप्त अवलोकन प्रारूप द्वारा सीमित है। मैं आपको पूरी सूची देखने के लिए आमंत्रित करता हूं। Pgbouncer एक तरह का सॉफ्टवेयर है जिसमें बहुत कम मात्रा में "उबाऊ सेटिंग्स" होती है - इन सभी में बहुत बड़ी क्षमता होती है और ये अद्भुत रुचि के होते हैं।

आज श्वेतपत्र डाउनलोड करें क्लस्टर नियंत्रण के साथ पोस्टग्रेएसक्यूएल प्रबंधन और स्वचालन इस बारे में जानें कि पोस्टग्रेएसक्यूएल को तैनात करने, निगरानी करने, प्रबंधित करने और स्केल करने के लिए आपको क्या जानना चाहिए। श्वेतपत्र डाउनलोड करें

और अंत में, एक छोटी उत्साही समीक्षा से किसी ऐसी चीज़ की ओर बढ़ना जहाँ आप कम खुश हो सकते हैं - स्थापना। दस्तावेज़ीकरण के इस खंड में प्रक्रिया को स्पष्ट रूप से वर्णित किया गया है। वर्णित एकमात्र विकल्प गिट स्रोतों से निर्माण कर रहा है। लेकिन हर कोई जानता है कि पैकेज हैं! दोनों सबसे लोकप्रिय कोशिश कर रहे हैं:

sudo yum install pgbouncer
sudo apt-get install pgbouncer

काम कर सकते हैं। लेकिन कभी-कभी आपको एक अतिरिक्त कदम उठाना पड़ता है। उदाहरण के लिए, जब कोई pgbouncer पैकेज उपलब्ध न हो, तो इसे आजमाएं।

या यहां तक कि:

sudo yum install pgbouncer
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main                                                                                                                    | 2.1 kB  00:00:00
amzn-updates                                                                                                                 | 2.5 kB  00:00:00
docker-ce-edge                                                                                                               | 2.9 kB  00:00:00
docker-ce-stable                                                                                                             | 2.9 kB  00:00:00
docker-ce-test                                                                                                               | 2.9 kB  00:00:00
pgdg10                                                                                                                       | 4.1 kB  00:00:00
pgdg95                                                                                                                       | 4.1 kB  00:00:00
pgdg96                                                                                                                       | 4.1 kB  00:00:00
pglogical                                                                                                                    | 3.0 kB  00:00:00
sensu                                                                                                                        | 2.5 kB  00:00:00
(1/3): pgdg96/x86_64/primary_db                                                                                              | 183 kB  00:00:00
(2/3): pgdg10/primary_db                                                                                                     | 151 kB  00:00:00
(3/3): pgdg95/x86_64/primary_db                                                                                              | 204 kB  00:00:00
50 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package pgbouncer.x86_64 0:1.8.1-1.rhel6 will be installed
--> Processing Dependency: libevent2 >= 2.0 for package: pgbouncer-1.8.1-1.rhel6.x86_64
--> Processing Dependency: c-ares for package: pgbouncer-1.8.1-1.rhel6.x86_64
--> Processing Dependency: libcares.so.2()(64bit) for package: pgbouncer-1.8.1-1.rhel6.x86_64
--> Running transaction check
---> Package c-ares.x86_64 0:1.13.0-1.5.amzn1 will be installed
---> Package pgbouncer.x86_64 0:1.8.1-1.rhel6 will be installed
--> Processing Dependency: libevent2 >= 2.0 for package: pgbouncer-1.8.1-1.rhel6.x86_64
--> Finished Dependency Resolution
Error: Package: pgbouncer-1.8.1-1.rhel6.x86_64 (pgdg10)
           Requires: libevent2 >= 2.0
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

बेशक pgdg को /etc/yum.repos.d/ में जोड़ने से अब कोई मदद नहीं मिलेगी। न तो --स्किप-टूटा या rpm -Va --nofiles --nodigest. एक साधारण

sudo yum install libevent2
Loaded plugins: priorities, update-motd, upgrade-helper
50 packages excluded due to repository priority protections
No package libevent2 available.
Error: Nothing to do

बहुत आसान होगा। तो आपको libevent2 का निर्माण स्वयं करना होगा, आपको उस स्थिति में वापस लाना होगा जब आपको चीजों को स्वयं संकलित करना होगा। या तो यह pgbouncer है या इसकी निर्भरता में से एक है।

फिर से - स्थापना की विशिष्टताओं के साथ बहुत गहरी खुदाई करना गुंजाइश से बाहर है। आपको पता होना चाहिए कि आपके पास इसे पैकेज के रूप में स्थापित करने का एक बड़ा मौका है।

अंत में - "क्यों पोस्टग्रेज एक देशी सत्र पूलर की पेशकश नहीं करता है" जैसे प्रश्न बार-बार आते हैं। इस पर बहुत ताजा सुझाव और विचार भी हैं। लेकिन अभी तक यहां सबसे लोकप्रिय तरीका pgbouncer का उपयोग कर रहा है।