PostgreSQL में उच्च उपलब्धता का प्रबंधन - भाग II:प्रतिकृति प्रबंधक

क्या आप PostgreSQL को क्लाउड में परिनियोजित कर रहे हैं और उच्च उपलब्धता प्राप्त करने के लिए अपने विकल्पों को समझना चाहते हैं? हमारे पिछले ब्लॉग पोस्ट में, PostgreSQL - भाग I में उच्च उपलब्धता का प्रबंधन, हमने ClusterLabs द्वारा PostgreSQL स्वचालित विफलता (PAF) की क्षमताओं और कार्यप्रणाली पर चर्चा की। भाग II में, हम आपको एक वैकल्पिक ओपन सोर्स टूल, 2ndQuadrant के प्रतिकृति प्रबंधक से परिचित करा रहे हैं, जिसके बाद भाग III का बारीकी से पालन किया जाएगा, जहां हम अपने तीसरे विकल्प, पेट्रोनी बाय ज़ालैंडो में गोता लगाते हैं।

PostgreSQL में उच्च उपलब्धता का प्रबंधन - भाग I:PostgreSQL स्वचालित विफलता
पोस्टग्रेएसक्यूएल में उच्च उपलब्धता का प्रबंधन - भाग III:पेट्रोनी

प्रतिकृति प्रबंधक (repmgr)

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

प्रतिकृति प्रबंधक PostgreSQL की प्रतिकृति और विफलता को प्रबंधित करने के लिए दो मुख्य उपकरण प्रदान करता है।

repmgr

एक कमांड-लाइन इंटरफ़ेस उपयोगिता जो आपको विभिन्न प्रशासनिक कार्यों को करने में सक्षम बनाती है।
repmgr आपको स्टैंडबाय सर्वर सेटअप करने, स्टैंडबाय को बढ़ावा देने, स्विचओवर करने और अपने PostgreSQL क्लस्टर की स्थिति की निगरानी करने में सक्षम बनाता है।
यह लगभग सभी प्रशासनिक कमांडों के लिए ड्राई रन विकल्प भी प्रदान करता है।

repmgrd

यह वह डेमॉन है जो:

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

यह कैसे काम करता है

repmrg न केवल PostgreSQL क्लस्टर की प्रतिकृति का प्रबंधन करता है, बल्कि प्रतिकृति के लिए स्टैंडबाय सर्वर स्थापित करने की क्षमता भी रखता है। प्रारंभिक स्थापना के बाद, हमें प्रत्येक सर्वर पर आवश्यक विवरण के साथ repmgr कॉन्फ़िगरेशन फ़ाइल (repmgr.conf) में परिवर्तन करने की आवश्यकता है। जब कोई सर्वर कॉन्फ़िगर किया जाता है, तो उसे repmgr प्राथमिक/स्टैंडबाय रजिस्टर कमांड का उपयोग करके repmgr के साथ पंजीकृत होने की आवश्यकता होती है। सबसे पहले, प्राथमिक नोड सेटअप और पंजीकृत है। फिर, स्टैंडबाय सर्वरों को repmgr स्टैंडबाय क्लोन कमांड का उपयोग करके बनाया और कॉन्फ़िगर किया जाता है जो किसी अन्य PostgreSQL सर्वर से PostgreSQL स्टैंडबाय नोड को क्लोन करता है।

प्रतिकृति प्रबंधक PostgreSQL एक्सटेंशन सुविधा का उपयोग करता है और क्लस्टर से संबंधित जानकारी संग्रहीत करने के लिए क्लस्टर डेटाबेस पर अपना स्वयं का स्कीमा बनाता है। विस्तार की स्थापना और स्कीमा का निर्माण प्राथमिक सर्वर के पंजीकरण के दौरान repmgr का उपयोग करते हुए होता है। एक बार सेटअप पूरा हो जाने के बाद, मैन्युअल प्रशासनिक संचालन जैसे कि प्रचार, अनुसरण, स्विचओवर, आदि को repmgr उपयोगिता का उपयोग करके किया जा सकता है। स्विचओवर ऑपरेशन के लिए, इसे नोड्स के बीच पासवर्ड रहित SSH सेटअप की आवश्यकता होती है।

repmgrd का उपयोग करके स्वचालित विफलता को सेटअप किया जा सकता है। PostgreSQL सर्वर को शुरू करते समय repmgrd को एक साझा लाइब्रेरी 'repmgr' लोड करने की आवश्यकता होती है। लाइब्रेरी के नाम का उल्लेख shared_preload_libraries . में किया जाना चाहिए postgresql.conf फ़ाइल में कॉन्फ़िगरेशन पैरामीटर। साथ ही, repmgrd के काम करने के लिए, failover=स्वचालित पैरामीटर को repmgr.conf फ़ाइल में सेट करने की आवश्यकता है। एक बार ये सभी पैरामीटर सेट हो जाने के बाद, repmgrd डेमॉन सक्रिय रूप से क्लस्टर की निगरानी करना शुरू कर देता है। यदि प्राथमिक नोड में कोई विफलता है, तो यह कई बार पुन:कनेक्ट करने का प्रयास करेगा। जब प्राथमिक से कनेक्ट करने के सभी प्रयास विफल हो जाते हैं, तो सबसे योग्य स्टैंडबाय को प्रतिनिधि द्वारा नए प्राथमिक के रूप में चुना जाता है।

repmgr भी इवेंट नोटिफिकेशन का समर्थन करता है। इसमें पूर्वनिर्धारित घटनाओं का एक सेट होता है और इन घटनाओं की प्रत्येक घटना को repmgr.events तालिका में संग्रहीत करता है। repmgr ईवेंट सूचनाओं को एक उपयोगकर्ता-परिभाषित प्रोग्राम या स्क्रिप्ट को पास करने में सक्षम बनाता है जो आगे की कार्रवाई कर सकता है, जैसे ईमेल भेजना या कोई अलर्ट ट्रिगर करना। यह event_notification_command . सेट करके किया जाता है repmgr.conf में पैरामीटर।

यह विभाजित मस्तिष्क परिदृश्य को कैसे संभालता है?

repmgr स्थान का उपयोग करके विभाजित मस्तिष्क परिदृश्यों से निपटता है पैरामीटर, जहां प्रत्येक नोड को डेटासेंटर के आधार पर स्थान पैरामीटर निर्दिष्ट करना चाहिए जिसमें इसे रखा गया है। किसी भी नेटवर्क विभाजन के मामले में, repmgr नोड के प्रचार को सुनिश्चित करेगा जो प्राथमिक के समान स्थान पर है। यदि उसे उस स्थान पर कोई नोड नहीं मिलता है, तो वह किसी भी स्थान पर किसी भी नोड का प्रचार नहीं करेगा।

यह क्लस्टर में सर्वरों की सम संख्या की स्थिति में नेटवर्क अलगाव को भी संभालता है। यह एक अतिरिक्त नोड का उपयोग करके किया जाता है जिसे विटनेस सर्वर कहा जाता है। विटनेस सर्वर एक नोड है जिसे केवल बहुमत मतों की गणना के लिए माना जाता है। उस सर्वर पर कोई PostgreSQL इंस्टॉलेशन नहीं होगा, और इसलिए, प्रतिकृति में खेलने के लिए कोई भूमिका नहीं होगी।

क्या कोई सेटअप आवश्यकताएँ हैं?

repmgr को एक समर्पित डेटाबेस और सुपरयुसर विशेषाधिकारों वाले उपयोगकर्ता की आवश्यकता होगी। हालांकि, अगर आप सुपरयूज़र को repmgr उपयोगकर्ता को एक्सेस देने के इच्छुक नहीं हैं, तो एक सुपरयूज़र प्रदान करने का विकल्प भी है।
यदि आप चाहते हैं कि repmgr कॉन्फ़िगरेशन फ़ाइलों की प्रतिलिपि बनाएँ जो PostgreSQL डेटा निर्देशिका के बाहर स्थित हैं, और/या स्विचओवर कार्यक्षमता का परीक्षण करने के लिए, आपको दोनों सर्वरों के बीच पासवर्ड रहित SSH कनेक्शन की भी आवश्यकता होगी, और rsync स्थापित होना चाहिए।
यदि आप pg_ctl (जो डिफ़ॉल्ट रूप से repmgr द्वारा उपयोग किया जाता है) के अलावा सेवा-आधारित कमांड का उपयोग शुरू करने, रोकने, पुनः लोड करने और पुनरारंभ करने के लिए करना चाहते हैं, तो आप उन्हें repmgr में निर्दिष्ट कर सकते हैं कॉन्फ़िगरेशन फ़ाइल (repmgr.conf).

Repmgr कॉन्फ़िगरेशन फ़ाइल में आवश्यक बुनियादी कॉन्फ़िगरेशन पैरामीटर इस प्रकार हैं:

नोड_आईडी (int) - शून्य से बड़ा एक अद्वितीय पूर्णांक जो नोड की पहचान करता है।नोड_नाम (स्ट्रिंग) - भ्रम से बचने के लिए सर्वर के होस्टनाम या स्पष्ट रूप से सर्वर से जुड़े किसी अन्य पहचानकर्ता का उपयोग करते हुए एक मनमाना (लेकिन अद्वितीय) स्ट्रिंग की सिफारिश की जाती है।

conninfo (स्ट्रिंग) - एक conninfo स्ट्रिंग के रूप में डेटाबेस कनेक्शन की जानकारी। क्लस्टर के सभी सर्वर इस स्ट्रिंग का उपयोग करके स्थानीय नोड से जुड़ने में सक्षम होने चाहिए।

data_directory (स्ट्रिंग) - नोड की डेटा निर्देशिका। जब PostgreSQL इंस्टेंस नहीं चल रहा हो और डेटा निर्देशिका निर्धारित करने का कोई अन्य तरीका नहीं है, तो ऑपरेशन करने के लिए repmgr द्वारा इसकी आवश्यकता होती है।

repmgr Pros

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

repmgr विपक्ष

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

#PostgreSQL में उच्च उपलब्धता को प्रबंधित करना - भाग II:ओपन सोर्स repmgr टूल ट्वीट करने के लिए क्लिक करें

उच्च उपलब्धता परीक्षण परिदृश्य

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

स्टैंडबाय सर्वर टेस्ट

<वें शैली="चौड़ाई:25%; लंबवत-संरेखण:मध्य; पृष्ठभूमि-रंग:#d9fce9;">परीक्षण परिदृश्य <वें शैली ="चौड़ाई:70%; लंबवत-संरेखण:मध्य; पृष्ठभूमि-रंग:#d9fce9;">निगरानी

Sl. नहीं
1	PostgreSQL प्रक्रिया को समाप्त करें	स्टैंडबाय सर्वर को विफल के रूप में चिह्नित किया गया था। लेखक आवेदन में कोई व्यवधान नहीं था। PostgreSQL प्रक्रिया को फिर से शुरू करने के लिए मैन्युअल हस्तक्षेप की आवश्यकता थी।
2	PostgreSQL प्रक्रिया को रोकें	स्टैंडबाय सर्वर को विफल के रूप में चिह्नित किया गया था। लेखक आवेदन में कोई व्यवधान नहीं था। PostgreSQL प्रक्रिया को फिर से शुरू करने के लिए मैन्युअल हस्तक्षेप की आवश्यकता थी।
3	सर्वर को रीबूट करें	स्टैंडबाय सर्वर को विफल के रूप में चिह्नित किया गया था। रिबूट के बाद सर्वर के आने के बाद, PostgreSQL को मैन्युअल रूप से शुरू किया गया था और सर्वर को रनिंग के रूप में चिह्नित किया गया था। लेखक आवेदन में कोई व्यवधान नहीं था।
4	repmgrd प्रक्रिया रोकें	स्टैंडबाय सर्वर स्वचालित विफलता स्थिति का हिस्सा नहीं होगा। PostgreSQL सेवा चल रही पाई गई। लेखक आवेदन में कोई व्यवधान नहीं था।

मास्टर/प्राथमिक सर्वर परीक्षण

Sl. नहीं	परीक्षण परिदृश्य	निगरानी
1	PostgreSQL प्रक्रिया को समाप्त करें	repmgrd ने एक निश्चित अंतराल के लिए सभी स्टैंडबाय सर्वरों पर प्राथमिक सर्वर कनेक्शन के लिए स्वास्थ्य जांच शुरू की। जब सभी पुनर्प्रयास विफल हो गए, तो सभी स्टैंडबाय सर्वरों पर एक चुनाव शुरू हो गया। चुनाव के परिणामस्वरूप, नवीनतम प्राप्त एलएसएन वाले स्टैंडबाय को पदोन्नत किया गया। जो स्टैंडबाय सर्वर चुनाव हार गए, वे नए मास्टर नोड से अधिसूचना की प्रतीक्षा करेंगे और सूचना मिलने के बाद उसका पालन करेंगे। लेखक के आवेदन में डाउनटाइम था। PostgreSQL प्रक्रिया को फिर से शुरू करने के लिए मैन्युअल हस्तक्षेप की आवश्यकता थी।
2	Stop the PostgreSQL process and bring it back immediately after health check expiry	repmgrd started the health check for the primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back. Cluster was left in an indeterminate state and manual intervention was required.
3	Reboot the server	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was ran to add the server back to the cluster. There was downtime in the writer application.
4	Stop the repmgr process	The primary server will not be a part of the automated failover situation. PostgreSQL service was found to be running. There was no disruption in the writer application.

Network Isolation Tests

Sl. No	Test Scenario	Observation
1	Network isolate the primary server from other servers (all have same value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted, but the PostgreSQL process was still running on the old master node. There were two nodes running as master. Manual intervention was required after the network isolation was corrected.
2	Network isolate the primary server from other servers (the standby servers has same value for location but primary had a different value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. But, there was no new master elected since the standby servers had a location different from that of the primary. repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.

Inference

repmgr provides several commands to setup and monitor PostgreSQL replication. It is feature-rich and also eases the job of the database administrator (DBA). However, it’s not a full fledged high availability management tool since it will not manage the resources. Manual intervention is required to ensure the resource is in proper state.

So, in this post, we’ve discussed the capabilities and workings of Replication Manager by 2ndQuadrant. In our next post, we’ll discuss the same high availability aspects using Patroni by Zalando. For users looking to automate their high availability in the cloud, check out our PostgreSQL on Azure and PostgreSQL on AWS fully managed solutions.