HAProxy के साथ PostgreSQL के लिए ड्राइविंग प्रदर्शन

आपके डेटाबेस क्लस्टर को बनाए रखते समय डेटाबेस प्रदर्शन एक बहुत ही महत्वपूर्ण चिंता का विषय है, खासकर जब यह समय के साथ बढ़ता है। यह विशेष रूप से सच है यदि आपका आवेदन कम ट्रैफ़िक के साथ शुरू हुआ और फिर मध्यम या भारी पठन-लेखन कार्यभार तक बढ़ रहा है।

याद रखने वाली बात यह है कि कोई भी सही कॉन्फ़िगरेशन नहीं है जिस पर आप लंबे समय तक भरोसा कर सकें, क्योंकि कुछ कार्यभार समय के साथ बदल सकते हैं।

ClusterControl के साथ, एक नया PostgreSQL डेटाबेस क्लस्टर बनाना या परिनियोजित करना एक बुनियादी विश्लेषण करता है जैसे कि आपके हार्डवेयर संसाधनों की जाँच करना, फिर ऑटो-ट्यूनिंग लागू करना और चयनित ट्यून करने योग्य मापदंडों के लिए मान सेट करना। जैसे ही PostgreSQL विकसित होता है, विभिन्न विन्यासों का समर्थन करने के लिए बहुत सारे उपकरण विकसित किए गए हैं, विशेष रूप से लोड संतुलन के लिए।

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

PostgreSQL प्रदर्शन ट्यूनिंग

PostgreSQL के प्रदर्शन को चलाने के लिए प्राथमिक कारकों में से एक मूल पैरामीटर को initdb से रनटाइम पैरामीटर मानों तक ट्यूनिंग के साथ शुरू होता है। यह आपकी कुछ आवश्यकताओं के अनुसार वांछित कार्यभार को संभालने में सक्षम होना चाहिए। इससे पहले कि हम PostgreSQL के लिए HAProxy सुविधा के लिए एक मार्ग ले सकें, आपके डेटाबेस सर्वर को स्थिर होना चाहिए और इसके वांछित चर के लिए ट्यून किया जाना चाहिए। आइए पोस्टग्रेएसक्यूएल के लिए क्षेत्रों की एक सूची लेते हैं कि ऐसी कौन सी चीजें हैं जो आपके डेटाबेस सर्वर के प्रदर्शन ड्राइव को प्रभावित कर सकती हैं।

व्यवहार्य स्मृति प्रबंधन के लिए ट्यूनिंग

PostgreSQL कुशल है और 256Mb जितनी कम मेमोरी में प्रभावी ढंग से चलाना संभव है। मेमोरी महंगी नहीं है, फिर भी अधिकांश डेटा सेट 4Gib से कम के हैं। यदि आपके पास कम से कम 4Gib है तो आपका सक्रिय डेटा सेट फ़ाइल और/या साझा_बफ़र कैश में बना रह सकता है।

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

साझा_बफ़र्स - PostgreSQL अपने मुख्य मेमोरी स्पेस को साझा_बफ़र्स के साथ आकार देता है। PostgreSQL के भीतर सभी हॉट टुपल्स (और इंडेक्स एंट्री) का वर्किंग कैश। यह पैरामीटर साझा मेमोरी बफ़र्स के लिए डेटाबेस सर्वर द्वारा उपयोग की जाने वाली मेमोरी की मात्रा निर्धारित करता है। यह एक पूर्व-आवंटित कैश (बफर) है। Linux आधारित सिस्टम के लिए, कर्नेल पैरामीटर kernel.shmmax को सेट करना आदर्श है जिसे /etc/sysctl.conf कर्नेल कॉन्फ़िगरेशन फ़ाइल के माध्यम से लगातार सेट किया जा सकता है।
temp_buffers - प्रत्येक सत्र के लिए उपयोग किए जाने वाले अस्थायी बफ़र्स की अधिकतम संख्या निर्धारित करता है। ये स्थानीय सत्र बफ़र हैं जिनका उपयोग केवल अस्थायी तालिकाओं तक पहुँचने के लिए किया जाता है। एक सत्र अस्थायी बफ़र्स को आवश्यकतानुसार temp_buffers द्वारा दी गई सीमा तक असाइन करेगा।
work_mem - PostgreSQL से पहले वर्क ऑपरेशंस (सॉर्ट्स) के लिए उपलब्ध वर्किंग मेमोरी स्वैप हो जाएगी। विश्व स्तर पर सेट न करें (postgresql.conf)। प्रति लेन-देन का उपयोग करें क्योंकि यह प्रति क्वेरी, प्रति कनेक्शन, या प्रति प्रकार खराब हो सकता है। यह देखने के लिए कि आप अतिप्रवाह कर रहे हैं या नहीं, EXPLAIN ANALYZE का उपयोग करने की अनुशंसा की जाती है।
रखरखाव_कार्य_मेम - रखरखाव कार्यों के लिए उपयोग की जाने वाली मेमोरी की मात्रा निर्दिष्ट करता है (वैक्यूम, इंडेक्स बनाएं, और तालिका बदलें ... विदेशी कुंजी जोड़ें ...)

व्यवहार्य डिस्क प्रबंधन के लिए ट्यूनिंग

यहां सेट करने के लिए कई रनटाइम पैरामीटर हैं। आइए सूचीबद्ध करें कि ये क्या हैं:

temp_file_limit - डिस्क स्थान की अधिकतम मात्रा निर्दिष्ट करता है जो सत्र अस्थायी फ़ाइलों के लिए उपयोग कर सकता है, जैसे सॉर्ट और हैश अस्थायी फ़ाइलें, या आयोजित कर्सर के लिए संग्रहण फ़ाइल। इस सीमा को पार करने का प्रयास करने वाला लेन-देन रद्द कर दिया जाएगा।
fsync - यदि fsync सक्षम है, तो PostgreSQL यह सुनिश्चित करने का प्रयास करेगा कि अद्यतन डिस्क पर भौतिक रूप से लिखे गए हैं। यह सुनिश्चित करता है कि ऑपरेटिंग सिस्टम या हार्डवेयर क्रैश के बाद डेटाबेस क्लस्टर को एक सुसंगत स्थिति में पुनर्प्राप्त किया जा सकता है। Fsync को अक्षम करने से आम तौर पर प्रदर्शन में सुधार होता है, यह बिजली की विफलता या सिस्टम क्रैश की स्थिति में डेटा हानि का कारण बन सकता है। इसलिए, fsync को निष्क्रिय करने की सलाह तभी दी जाती है जब आप बाहरी डेटा से अपने संपूर्ण डेटाबेस को आसानी से फिर से बना सकें
सिंक्रोनस_प्रतिबद्ध - यह लागू करने के लिए उपयोग किया जाता है कि ग्राहक को सफलता की स्थिति वापस करने से पहले डिस्क पर WAL के लिखे जाने की प्रतीक्षा होगी। इस चर में प्रदर्शन और विश्वसनीयता के बीच ट्रेड-ऑफ है। यदि आपको अधिक प्रदर्शन की आवश्यकता है, तो इसे बंद पर सेट करें, जिसका अर्थ है कि जब सर्वर क्रैश हो जाता है, तो डेटा हानि का सामना करने की प्रवृत्ति होती है। अन्यथा, यदि विश्वसनीयता महत्वपूर्ण है, तो इसे चालू रखें। इसका मतलब है कि सफलता की स्थिति और डिस्क पर गारंटीकृत लेखन के बीच एक समय अंतराल होगा, इस प्रकार यह प्रदर्शन को प्रभावित कर सकता है।
checkpoint_timeout, checkpoint_completion_target - PostgreSQL WAL में परिवर्तन लिखता है, जो एक महंगा ऑपरेशन है। यदि यह बार-बार वाल में परिवर्तन लिख रहा है, तो यह प्रदर्शन को खराब तरीके से प्रभावित कर सकता है। तो यह कैसे काम करता है, चेकपॉइंट प्रक्रिया डेटा को डेटा फ़ाइलों में फ़्लश करती है। यह गतिविधि तब की जाती है जब CHECKPOINT होता है और बड़ी मात्रा में IO का कारण बन सकता है। इस पूरी प्रक्रिया में महंगी डिस्क रीड/राइट ऑपरेशंस शामिल हैं। यद्यपि आप (व्यवस्थापक उपयोगकर्ता) जब भी आवश्यक लगता है, हमेशा CHECKPOINT जारी कर सकते हैं या इन मापदंडों के लिए वांछित मान सेट करके इसे स्वचालित कर सकते हैं। WAL चौकियों के बीच समय निर्धारित करने के लिए checkpoint_timeout पैरामीटर का उपयोग किया जाता है। इसे बहुत कम सेट करने से क्रैश रिकवरी समय कम हो जाता है, क्योंकि डिस्क पर अधिक डेटा लिखा जाता है, लेकिन यह प्रदर्शन को भी नुकसान पहुंचाता है क्योंकि प्रत्येक चेकपॉइंट मूल्यवान सिस्टम संसाधनों का उपभोग करता है। checkpoint_completion_target चेकपॉइंट के पूरा होने के लिए चौकियों के बीच समय का अंश है। चौकियों की एक उच्च आवृत्ति प्रदर्शन को प्रभावित कर सकती है। सुचारू चेकपॉइंटिंग के लिए, checkpoint_timeout कम मान होना चाहिए। अन्यथा ओएस सभी गंदे पृष्ठों को तब तक जमा करेगा जब तक कि अनुपात पूरा नहीं हो जाता और फिर एक बड़े फ्लश के लिए चला जाता है।

प्रदर्शन के लिए अन्य पैरामीटर ट्यून करना

कुछ निश्चित पैरामीटर हैं जो PostgreSQL में प्रदर्शन के लिए बढ़ावा और ड्राइव प्रदान करते हैं। आइए सूचीबद्ध करें कि ये नीचे क्या हैं:

wal_buffers - PostgreSQL अपने WAL (आगे लॉग लिखें) रिकॉर्ड को बफ़र्स में लिखता है और फिर इन बफ़र्स को डिस्क पर फ़्लश कर दिया जाता है। wal_buffers द्वारा परिभाषित बफ़र का डिफ़ॉल्ट आकार 16MB है, लेकिन यदि आपके पास बहुत सारे समवर्ती कनेक्शन हैं तो एक उच्च मान बेहतर प्रदर्शन दे सकता है।
प्रभावी_कैश_साइज - प्रभावी_कैश_साइज डिस्क कैशिंग के लिए उपलब्ध स्मृति का अनुमान प्रदान करता है। यह सिर्फ एक दिशानिर्देश है, सटीक आवंटित स्मृति या कैश आकार नहीं। यह वास्तविक मेमोरी आवंटित नहीं करता है लेकिन ऑप्टिमाइज़र को कर्नेल में उपलब्ध कैश की मात्रा बताता है। यदि इसका मान बहुत कम है, तो क्वेरी प्लानर कुछ इंडेक्स का उपयोग नहीं करने का निर्णय ले सकता है, भले ही वे सहायक हों। इसलिए, बड़ा मान सेट करना हमेशा फायदेमंद होता है।
default_statistics_target - PostgreSQL अपने डेटाबेस में प्रत्येक तालिका से आंकड़े एकत्र करता है ताकि यह तय किया जा सके कि उन पर प्रश्नों को कैसे निष्पादित किया जाएगा। डिफ़ॉल्ट रूप से, यह बहुत अधिक जानकारी एकत्र नहीं करता है, और यदि आपको अच्छी निष्पादन योजनाएँ नहीं मिल रही हैं, तो आपको इस मान को बढ़ाना चाहिए और फिर डेटाबेस में ANALYZE को फिर से चलाना चाहिए (या AUTOVACUUM की प्रतीक्षा करें)।

PostgreSQL क्वेरी दक्षता

PostgreSQL में प्रश्नों को अनुकूलित करने के लिए एक बहुत ही शक्तिशाली विशेषता है। बिल्ट-इन जेनेटिक क्वेरी ऑप्टिमाइज़र (GEQO के रूप में जाना जाता है) के साथ। यह एक आनुवंशिक एल्गोरिथ्म का उपयोग करता है जो यादृच्छिक खोज के माध्यम से एक अनुमानी अनुकूलन विधि है। यह जॉइन का उपयोग करते हुए अनुकूलन करते समय लागू किया जाता है जो एक बहुत अच्छा प्रदर्शन अनुकूलन प्रदान करता है। जॉइन प्लान में प्रत्येक उम्मीदवार को एक अनुक्रम द्वारा दर्शाया जाता है जिसमें आधार संबंधों में शामिल होना है। यह बेतरतीब ढंग से कुछ संभावित जुड़ाव अनुक्रम उत्पन्न करके लेकिन यादृच्छिक रूप से आनुवंशिक संबंध करता है।

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

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

पढ़ने-लिखने के विभाजन के साथ PostgreSQL के लिए ड्राइविंग प्रदर्शन

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

HAProxy के साथ सेटअप करना आसान है। फिर भी, यह क्लस्टरकंट्रोल के साथ अधिक कुशलता से तेज और व्यवहार्य है। इसलिए हम इसे अपने लिए सेट करने के लिए ClusterControl का उपयोग करेंगे।

HAProxy के साथ PostgreSQL सेट करना

ऐसा करने के लिए, हमें केवल PostgreSQL क्लस्टर के शीर्ष पर HAProxy को स्थापित और सेटअप करना होगा। HAProxy में विकल्प pgsql-check के माध्यम से PostgreSQL का समर्थन करने की सुविधा है, लेकिन इसका समर्थन यह निर्धारित करने के लिए एक बहुत ही सरल कार्यान्वयन है कि कोई नोड ऊपर है या नहीं। इसमें प्राथमिक और पुनर्प्राप्ति नोड की पहचान करने के लिए कोई जांच नहीं है। एक विकल्प xinetd का उपयोग करना है जिसके लिए हम अपनी xinetd सेवा के माध्यम से सुनने के लिए HAProxy को संचार करने पर भरोसा करेंगे जो हमारे PostgreSQL क्लस्टर में किसी विशेष नोड के स्वास्थ्य की जांच करता है।

ClusterControl के अंतर्गत, मैनेज पर नेविगेट करें → ठीक नीचे बैलेंसर लोड करें,

फिर नीचे दिए गए स्क्रीनशॉट के अनुसार UI के आधार पर फॉलो करें। अधिक उन्नत विकल्प देखने के लिए आप उन्नत सेटिंग्स दिखाएँ पर क्लिक कर सकते हैं। हालाँकि UI का अनुसरण करना बहुत सीधा है। नीचे देखें,

मैं अतिरेक के बिना केवल एकल नोड HAProxy का आयात कर रहा हूं, लेकिन इसके उद्देश्य के लिए यह ब्लॉग, आइए इसे आसान बनाते हैं।

मेरा नमूना HAProxy दृश्य नीचे दिखाया गया है,

जैसा कि ऊपर दिखाया गया है, 192.168.30.20 और 192.168.30.30 प्राथमिक हैं और माध्यमिक/वसूली नोड्स क्रमशः। जबकि द्वितीयक/पुनर्प्राप्ति नोड में HAProxy स्थापित है। आदर्श रूप से, आप अपने HAProxy को अधिक अतिरेक और अत्यधिक उपलब्ध होने के लिए कई नोड्स पर स्थापित कर सकते हैं, इसे डेटाबेस नोड्स के विरुद्ध अलग करना सबसे अच्छा है। यदि आप बजट पर तंग हैं या अपने उपयोग को कम कर रहे हैं, तो आप अपने HAProxy नोड्स को स्थापित करने का विकल्प चुन सकते हैं, जहां आपके डेटाबेस नोड्स भी स्थापित हैं।

ClusterControl इसे स्वचालित रूप से सेटअप करता है और इसमें PostgreSQL चेक के लिए xinetd सेवा भी शामिल है। इसे नीचे की तरह netstat से सत्यापित किया जा सकता है,

[email protected]:~# netstat -tlv4np|grep haproxy

tcp        0      0 0.0.0.0:5433            0.0.0.0:*               LISTEN      28441/haproxy

tcp        0      0 0.0.0.0:5434            0.0.0.0:*               LISTEN      28441/haproxy

tcp        0      0 0.0.0.0:9600            0.0.0.0:*               LISTEN      28441/haproxy

जबकि पोर्ट 5433 रीड-राइट है और 5444 केवल-पढ़ने के लिए है।

PostgreSQL के लिए xinetd सेवा के लिए जाँच करें, जिसका नाम नीचे दिया गया है, जैसा कि नीचे देखा गया है,

[email protected]:~# cat /etc/xinetd.d/postgreschk

# default: on

# description: postgreschk

service postgreschk

{

        flags           = REUSE

        socket_type     = stream

        port            = 9201

        wait            = no

        user            = root

        server          = /usr/local/sbin/postgreschk

        log_on_failure  += USERID

        disable         = no

        #only_from       = 0.0.0.0/0

        only_from       = 0.0.0.0/0

        per_source      = UNLIMITED

}

xinetd सेवाएं भी /etc/services पर निर्भर करती हैं ताकि आप उस पोर्ट को ढूंढ सकें जिसे मैप करने के लिए निर्दिष्ट किया गया है।

[email protected]:~# grep postgreschk /etc/services

postgreschk        9201/tcp

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

पी>

पोस्टग्रेस्क सेवा में एक बाहरी फ़ाइल का संदर्भ होता है जो मूल रूप से नोड्स के लिए एक जांच करता है यदि यह लिखने योग्य है, जिसका अर्थ है कि यह प्राथमिक या मास्टर है। यदि कोई नोड पुनर्प्राप्ति में है, तो यह एक प्रतिकृति या पुनर्प्राप्ति नोड है।

[email protected]:~# cat /usr/local/sbin/postgreschk

#!/bin/bash

#

# This script checks if a PostgreSQL server is healthy running on localhost. It will

# return:

# "HTTP/1.x 200 OK\r" (if postgres is running smoothly)

# - OR -

# "HTTP/1.x 500 Internal Server Error\r" (else)

#

# The purpose of this script is make haproxy capable of monitoring PostgreSQL properly

#



export PGHOST='localhost'

export PGUSER='s9smysqlchk'

export PGPASSWORD='password'

export PGPORT='7653'

export PGDATABASE='postgres'

export PGCONNECT_TIMEOUT=10



FORCE_FAIL="/dev/shm/proxyoff"



SLAVE_CHECK="SELECT pg_is_in_recovery()"

WRITABLE_CHECK="SHOW transaction_read_only"



return_ok()

{

    echo -e "HTTP/1.1 200 OK\r\n"

    echo -e "Content-Type: text/html\r\n"

    if [ "$1x" == "masterx" ]; then

        echo -e "Content-Length: 56\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL master is running.</body></html>\r\n"

    elif [ "$1x" == "slavex" ]; then

        echo -e "Content-Length: 55\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL slave is running.</body></html>\r\n"

    else

        echo -e "Content-Length: 49\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL is running.</body></html>\r\n"

    fi

    echo -e "\r\n"



    unset PGUSER

    unset PGPASSWORD

    exit 0

}



return_fail()

{

    echo -e "HTTP/1.1 503 Service Unavailable\r\n"

    echo -e "Content-Type: text/html\r\n"

    echo -e "Content-Length: 48\r\n"

    echo -e "\r\n"

    echo -e "<html><body>PostgreSQL is *down*.</body></html>\r\n"

    echo -e "\r\n"



    unset PGUSER

    unset PGPASSWORD

    exit 1

}



if [ -f "$FORCE_FAIL" ]; then

    return_fail;

fi



# check if in recovery mode (that means it is a 'slave')

SLAVE=$(psql -qt -c "$SLAVE_CHECK" 2>/dev/null)

if [ $? -ne 0 ]; then

    return_fail;

elif echo $SLAVE | egrep -i "(t|true|on|1)" 2>/dev/null >/dev/null; then

    return_ok "slave"

fi



# check if writable (then we consider it as a 'master')

READONLY=$(psql -qt -c "$WRITABLE_CHECK" 2>/dev/null)

if [ $? -ne 0 ]; then

    return_fail;

elif echo $READONLY | egrep -i "(f|false|off|0)" 2>/dev/null >/dev/null; then

    return_ok "master"

fi



return_ok "none";

उपयोगकर्ता/पासवर्ड संयोजन आपके PostgreSQL सर्वर में एक मान्य ROLE होना चाहिए। चूंकि हम ClusterControl के माध्यम से इंस्टॉल कर रहे हैं, यह स्वचालित रूप से नियंत्रित किया जाता है।

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