🥇पोस्टग्रेएसक्यूएल + पेट्रोनी फेलओवर क्लस्टर। कार्यान्वयन का अनुभव

लेख में मैं आपको बताऊंगा कि हमने PostgreSQL दोष सहिष्णुता के मुद्दे पर कैसे संपर्क किया, यह हमारे लिए क्यों महत्वपूर्ण हो गया और अंत में क्या हुआ।

हमारे पास अत्यधिक भरी हुई सेवा है: दुनिया भर में 2,5 मिलियन उपयोगकर्ता, हर दिन 50K+ सक्रिय उपयोगकर्ता। सर्वर आयरलैंड के एक क्षेत्र में अमेज़ॅन में स्थित हैं: 100+ विभिन्न सर्वर लगातार काम कर रहे हैं, जिनमें से लगभग 50 डेटाबेस के साथ हैं।

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

हमने Redis से PostgreSQL पर स्विच क्यों किया

प्रारंभ में, हमारी सेवा रेडिस के साथ काम करती थी, जो एक कुंजी-मूल्य स्टोर है जो सर्वर की रैम में सभी डेटा संग्रहीत करता है।

रेडिस के पेशेवर:

उच्च प्रतिक्रिया गति, क्योंकि सब कुछ स्मृति में संग्रहीत है;
बैकअप और प्रतिकृति में आसानी.

हमारे लिए रेडिस के विपक्ष:

कोई वास्तविक लेन-देन नहीं है. हमने अपने एप्लिकेशन के स्तर पर उनका अनुकरण करने का प्रयास किया। दुर्भाग्य से, यह हमेशा अच्छी तरह से काम नहीं करता था और इसके लिए बहुत जटिल कोड लिखने की आवश्यकता होती थी।
डेटा की मात्रा मेमोरी की मात्रा से सीमित होती है। जैसे-जैसे डेटा की मात्रा बढ़ेगी, मेमोरी बढ़ेगी, और अंत में, हम चयनित इंस्टेंस की विशेषताओं में चलेंगे, जिसके लिए AWS में इंस्टेंस के प्रकार को बदलने के लिए हमारी सेवा को रोकने की आवश्यकता होती है।
निम्न विलंबता स्तर को लगातार बनाए रखना आवश्यक है, क्योंकि. हमारे पास बहुत बड़ी संख्या में अनुरोध हैं। हमारे लिए इष्टतम विलंब स्तर 17-20 एमएस है। 30-40 एमएस के स्तर पर, हमें अपने आवेदन और सेवा में गिरावट के अनुरोधों पर लंबी प्रतिक्रियाएँ मिलती हैं। दुर्भाग्य से, सितंबर 2018 में हमारे साथ ऐसा हुआ, जब रेडिस के एक उदाहरण में किसी कारण से सामान्य से 2 गुना अधिक विलंबता प्राप्त हुई। समस्या को हल करने के लिए, हमने अनिर्धारित रखरखाव के लिए मध्याह्न में सेवा बंद कर दी और समस्याग्रस्त रेडिस इंस्टेंस को बदल दिया।
कोड में छोटी त्रुटियों के साथ भी डेटा असंगतता प्राप्त करना आसान है और फिर इस डेटा को सही करने के लिए कोड लिखने में बहुत समय व्यतीत होता है।

हमने कमियों को ध्यान में रखा और महसूस किया कि हमें सामान्य लेनदेन और विलंबता पर कम निर्भरता के साथ कुछ अधिक सुविधाजनक चीज़ की ओर बढ़ने की ज़रूरत है। शोध किया, कई विकल्पों का विश्लेषण किया और PostgreSQL को चुना।

हम 1,5 वर्षों से एक नए डेटाबेस पर जा रहे हैं और डेटा का केवल एक छोटा सा हिस्सा ही स्थानांतरित कर पाए हैं, इसलिए अब हम Redis और PostgreSQL के साथ एक साथ काम कर रहे हैं। डेटाबेस के बीच डेटा ले जाने और स्विच करने के चरणों के बारे में अधिक जानकारी इसमें लिखी गई है मेरे सहकर्मी का लेख.

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

पीजीबाउंसर का कार्यान्वयन

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

हमारे पास कनेक्शन मैनेजर के लिए दो विकल्प थे: Pgpool और PgBouncer। लेकिन पहला डेटाबेस के साथ काम करने के लेन-देन मोड का समर्थन नहीं करता है, इसलिए हमने PgBouncer को चुना।

हमने कार्य की निम्नलिखित योजना स्थापित की है: हमारा एप्लिकेशन एक PgBouncer तक पहुंचता है, जिसके पीछे PostgreSQL मास्टर्स होते हैं, और प्रत्येक मास्टर के पीछे एसिंक्रोनस प्रतिकृति के साथ एक प्रतिकृति होती है।

उसी समय, हम PostgreSQL में संपूर्ण डेटा संग्रहीत नहीं कर सके और डेटाबेस के साथ काम करने की गति हमारे लिए महत्वपूर्ण थी, इसलिए हमने एप्लिकेशन स्तर पर PostgreSQL को साझा करना शुरू कर दिया। ऊपर वर्णित योजना इसके लिए अपेक्षाकृत सुविधाजनक है: एक नया PostgreSQL शार्ड जोड़ते समय, यह PgBouncer कॉन्फ़िगरेशन को अपडेट करने के लिए पर्याप्त है और एप्लिकेशन तुरंत नए शार्ड के साथ काम कर सकता है।

पीजीबाउंसर विफलता

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

उसके बाद, हमने PgBouncer और PostgreSQL क्लस्टर की दोष सहनशीलता के बारे में गंभीरता से सोचा, क्योंकि हमारे AWS खाते में किसी भी उदाहरण के साथ ऐसी ही स्थिति हो सकती है।

हमने PgBouncer दोष सहिष्णुता योजना इस प्रकार बनाई: सभी एप्लिकेशन सर्वर नेटवर्क लोड बैलेंसर तक पहुंचते हैं, जिसके पीछे दो PgBouncers होते हैं। प्रत्येक PgBouncer प्रत्येक शार्ड के समान PostgreSQL मास्टर को देखता है। यदि AWS इंस्टेंस क्रैश दोबारा होता है, तो सारा ट्रैफ़िक दूसरे PgBouncer के माध्यम से पुनर्निर्देशित हो जाता है। नेटवर्क लोड बैलेंसर फेलओवर AWS द्वारा प्रदान किया जाता है।

यह योजना नए PgBouncer सर्वर को जोड़ना आसान बनाती है।

एक PostgreSQL फेलओवर क्लस्टर बनाएं

इस समस्या को हल करते समय, हमने विभिन्न विकल्पों पर विचार किया: स्व-लिखित फेलओवर, रिपएमजीआर, एडब्ल्यूएस आरडीएस, पेट्रोनी।

स्व-लिखित स्क्रिप्ट

वे मास्टर के काम की निगरानी कर सकते हैं और, यदि यह विफल हो जाता है, तो मास्टर को प्रतिकृति को बढ़ावा दें और PgBouncer कॉन्फ़िगरेशन को अपडेट करें।

इस दृष्टिकोण का लाभ अधिकतम सरलता है, क्योंकि आप स्वयं स्क्रिप्ट लिखते हैं और समझते हैं कि वे कैसे काम करती हैं।

विपक्ष:

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

स्व-लिखित विफलता बहुत जटिल लगती है और इसके लिए गैर-तुच्छ समर्थन की आवश्यकता होती है। एकल PostgreSQL क्लस्टर के साथ, यह सबसे आसान विकल्प होगा, लेकिन यह स्केल नहीं करता है, इसलिए यह हमारे लिए उपयुक्त नहीं है।

Repmgr

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

एडब्ल्यूएस आरडीएस

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

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

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

इसके अलावा, AWS RDS नियमित इंस्टेंस कीमत से लगभग दोगुना महंगा है, जो इस समाधान को छोड़ने का मुख्य कारण था।

संरक्षक

यह अच्छे दस्तावेज़ीकरण, स्वचालित फ़ेलओवर और जीथब पर स्रोत कोड के साथ PostgreSQL को प्रबंधित करने के लिए एक पायथन टेम्पलेट है।

पेट्रोनी के पेशेवर:

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

विपक्ष:

दस्तावेज़ से यह स्पष्ट नहीं है कि PgBouncer के साथ सही तरीके से कैसे काम किया जाए। हालाँकि इसे माइनस कहना कठिन है, क्योंकि पेट्रोनी का कार्य PostgreSQL को प्रबंधित करना है, और पेट्रोनी से कनेक्शन कैसे होगा यह पहले से ही हमारी समस्या है;
बड़ी मात्रा में पेट्रोनी के कार्यान्वयन के कुछ उदाहरण हैं, जबकि शुरुआत से कार्यान्वयन के कई उदाहरण हैं।

परिणामस्वरूप, हमने फेलओवर क्लस्टर बनाने के लिए पेट्रोनी को चुना।

पेट्रोनी कार्यान्वयन प्रक्रिया

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

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

पेट्रोनी कंसल के साथ कैसे काम करती है

हमारे पास एक कॉन्सल क्लस्टर है, जिसमें तीन नोड्स होते हैं, और एक पेट्रोनी क्लस्टर, जिसमें एक लीडर और एक प्रतिकृति होती है (पैट्रोनी में, मास्टर को क्लस्टर लीडर कहा जाता है, और दासों को प्रतिकृतियां कहा जाता है)। पेट्रोनी क्लस्टर का प्रत्येक उदाहरण लगातार क्लस्टर की स्थिति के बारे में कॉन्सल को जानकारी भेजता है। इसलिए, कौंसल से आप हमेशा पैट्रोनी क्लस्टर की वर्तमान कॉन्फ़िगरेशन का पता लगा सकते हैं और इस समय नेता कौन है।

पेट्रोनी को कॉन्सल से जोड़ने के लिए, आधिकारिक दस्तावेज का अध्ययन करना पर्याप्त है, जो कहता है कि आपको HTTP या https प्रारूप में एक होस्ट निर्दिष्ट करने की आवश्यकता है, यह इस पर निर्भर करता है कि हम कॉन्सल के साथ कैसे काम करते हैं, और कनेक्शन योजना, वैकल्पिक रूप से:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

यह सरल दिखता है, लेकिन यहीं से ख़तरे शुरू होते हैं। कॉन्सल के साथ, हम https के माध्यम से एक सुरक्षित कनेक्शन पर काम करते हैं और हमारा कनेक्शन कॉन्फ़िगरेशन इस तरह दिखेगा:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

लेकिन वह काम नहीं करता. स्टार्टअप पर, पेट्रोनी कॉन्सल से कनेक्ट नहीं हो सकता, क्योंकि यह वैसे भी http से गुजरने की कोशिश करता है।

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

कौंसुल-टेम्पलेट

इसलिए, हमने कॉन्फ़िगरेशन के लिए स्टोरेज को चुना है। अब हमें यह समझने की जरूरत है कि पैट्रोनी क्लस्टर में लीडर बदलते समय PgBouncer अपना कॉन्फ़िगरेशन कैसे बदलेगा। दस्तावेज़ में इस प्रश्न का कोई उत्तर नहीं है, क्योंकि. वहाँ, सिद्धांत रूप में, PgBouncer के साथ काम का वर्णन नहीं किया गया है।

समाधान की तलाश में, हमें एक लेख मिला (दुर्भाग्य से मुझे शीर्षक याद नहीं है) जहां लिखा था कि कंसल-टेम्पलेट ने पीजीबाउंसर और पैट्रोनी को जोड़ने में बहुत मदद की। इसने हमें यह जांचने के लिए प्रेरित किया कि कॉन्सल-टेम्पलेट कैसे काम करता है।

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

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

पेट्रोनी के साथ नई वास्तुकला

परिणामस्वरूप, हमें निम्नलिखित कार्य योजना मिली:

सभी एप्लिकेशन सर्वर बैलेंसर तक पहुंचते हैं → इसके पीछे PgBouncer के दो उदाहरण हैं → प्रत्येक उदाहरण पर, कॉन्सल-टेम्पलेट लॉन्च किया जाता है, जो प्रत्येक पेट्रोनी क्लस्टर की स्थिति की निगरानी करता है और PgBouncer कॉन्फिगरेशन की प्रासंगिकता की निगरानी करता है, जो वर्तमान लीडर को अनुरोध भेजता है प्रत्येक क्लस्टर का.

मैनुअल परीक्षण

हमने इस योजना को एक छोटे परीक्षण वातावरण में लॉन्च करने से पहले चलाया और स्वचालित स्विचिंग के संचालन की जाँच की। उन्होंने बोर्ड खोला, स्टिकर हटाया और उसी क्षण उन्होंने समूह के नेता को "मार डाला"। AWS में, यह कंसोल के माध्यम से इंस्टेंस को बंद करने जितना सरल है।

स्टिकर 10-20 सेकंड के भीतर वापस लौट आया और फिर सामान्य रूप से चलने लगा। इसका मतलब है कि पैट्रोनी क्लस्टर ने सही ढंग से काम किया: इसने लीडर को बदल दिया, कॉन्सल को जानकारी भेज दी, और कॉन्सुल-टेम्पलेट ने तुरंत इस जानकारी को उठाया, पीजीबाउंसर कॉन्फ़िगरेशन को बदल दिया और पुनः लोड करने के लिए कमांड भेजा।

उच्च भार के तहत कैसे जीवित रहें और डाउनटाइम को न्यूनतम कैसे रखें?

सब कुछ पूरी तरह से काम करता है! लेकिन नए प्रश्न हैं: यह उच्च भार के तहत कैसे काम करेगा? उत्पादन में हर चीज़ को जल्दी और सुरक्षित तरीके से कैसे रोल आउट करें?

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

दोनों कार्य महत्वाकांक्षी लगते हैं, लेकिन हमारे पास PostgreSQL 9.6 है। क्या हम तुरंत 11.2 में अपग्रेड कर सकते हैं?

हमने इसे 2 चरणों में करने का निर्णय लिया है: पहले 11.2 पर अपग्रेड करें, फिर पेट्रोनी लॉन्च करें।

पोस्टग्रेएसक्यूएल अपडेट

PostgreSQL संस्करण को शीघ्रता से अपडेट करने के लिए, विकल्प का उपयोग करें -k, जिसमें डिस्क पर हार्ड लिंक बनाए जाते हैं और आपके डेटा को कॉपी करने की कोई आवश्यकता नहीं होती है। 300-400 जीबी के आधार पर, अपडेट में 1 सेकंड का समय लगता है।

हमारे पास बहुत सारे टुकड़े हैं, इसलिए अपडेट को स्वचालित रूप से करने की आवश्यकता है। ऐसा करने के लिए, हमने एक अन्सिबल प्लेबुक लिखी जो हमारे लिए संपूर्ण अद्यतन प्रक्रिया को संभालती है:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

पेट्रोनी लॉन्च करें

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

जब हमने पहले से मौजूद PostgreSQL क्लस्टर पर Patroni को स्थापित करना और उसे चलाना शुरू किया, तो हमें एक नई समस्या का सामना करना पड़ा: दोनों सर्वर एक लीडर के रूप में शुरू हुए। पेट्रोनी को क्लस्टर की प्रारंभिक स्थिति के बारे में कुछ नहीं पता है और वह दोनों सर्वरों को एक ही नाम से दो अलग-अलग क्लस्टर के रूप में शुरू करने का प्रयास करता है। इस समस्या को हल करने के लिए, आपको स्लेव पर डेटा वाली निर्देशिका को हटाना होगा:

rm -rf /var/lib/postgresql/

यह केवल गुलाम पर ही करने की जरूरत है!

जब एक साफ प्रतिकृति कनेक्ट होती है, तो पेट्रोनी एक बेसबैकअप लीडर बनाता है और इसे प्रतिकृति में पुनर्स्थापित करता है, और फिर वॉल लॉग के अनुसार वर्तमान स्थिति को पकड़ता है।

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

लोड परीक्षण

हमने एक परीक्षण लॉन्च किया है जो बोर्डों पर उपयोगकर्ता अनुभव का अनुकरण करता है। जब लोड हमारे औसत दैनिक मूल्य पर पहुंच गया, तो हमने बिल्कुल वही परीक्षण दोहराया, हमने PostgreSQL लीडर के साथ एक उदाहरण को बंद कर दिया। स्वचालित फ़ेलओवर ने हमारी अपेक्षा के अनुरूप काम किया: पेट्रोनी ने लीडर बदल दिया, कॉन्सल-टेम्पलेट ने PgBouncer कॉन्फ़िगरेशन को अपडेट किया और पुनः लोड करने के लिए एक कमांड भेजा। ग्राफाना में हमारे ग्राफ़ के अनुसार, यह स्पष्ट था कि डेटाबेस से कनेक्शन से जुड़े सर्वर से 20-30 सेकंड की देरी और थोड़ी मात्रा में त्रुटियां थीं। यह एक सामान्य स्थिति है, ऐसे मूल्य हमारे फेलओवर के लिए स्वीकार्य हैं और निश्चित रूप से सेवा डाउनटाइम से बेहतर हैं।

पेट्रोनी को उत्पादन में लाना

परिणामस्वरूप, हम निम्नलिखित योजना लेकर आए:

PgBouncer सर्वर पर कॉन्सल-टेम्पलेट तैनात करें और लॉन्च करें;
PostgreSQL संस्करण 11.2 में अद्यतन;
क्लस्टर का नाम बदलें;
पेट्रोनी क्लस्टर शुरू करना।

साथ ही, हमारी योजना हमें लगभग किसी भी समय पहला बिंदु बनाने की अनुमति देती है, हम प्रत्येक PgBouncer को बारी-बारी से काम से हटा सकते हैं और उस पर कॉन्सल-टेम्पलेट को तैनात और चला सकते हैं। तो हमने किया.

त्वरित परिनियोजन के लिए, हमने Ansible का उपयोग किया, क्योंकि हमने पहले ही परीक्षण वातावरण पर सभी प्लेबुक का परीक्षण कर लिया है, और पूर्ण स्क्रिप्ट का निष्पादन समय प्रत्येक शार्ड के लिए 1,5 से 2 मिनट तक था। हम अपनी सेवा को बंद किए बिना प्रत्येक शार्ड में बारी-बारी से सब कुछ रोल आउट कर सकते हैं, लेकिन हमें प्रत्येक PostgreSQL को कई मिनटों के लिए बंद करना होगा। इस मामले में, जिन उपयोगकर्ताओं का डेटा इस शार्ड पर है, वे इस समय पूरी तरह से काम नहीं कर सकते हैं, और यह हमारे लिए अस्वीकार्य है।

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

हमने अपनी सेवा फिर से शुरू की, सब कुछ वैसा ही काम करता रहा जैसा उसे करना चाहिए, उपयोगकर्ता काम करते रहे, लेकिन ग्राफ़ पर हमने कॉन्सल सर्वर पर असामान्य रूप से उच्च लोड देखा।

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

पेट्रोनी क्लस्टर को पुनरारंभ करें

हालाँकि, हमें एक नई समस्या मिली, जिसके बारे में हमें संदेह भी नहीं था। कॉन्सल को अपडेट करते समय, हम कॉन्सल लीव कमांड का उपयोग करके क्लस्टर से कॉन्सल नोड को हटा देते हैं → पैट्रोनी दूसरे कॉन्सल सर्वर से जुड़ जाता है → सब कुछ काम करता है। लेकिन जब हम कॉन्सल क्लस्टर के अंतिम उदाहरण पर पहुंचे और उसे कॉन्सल लीव कमांड भेजा, तो सभी पेट्रोनी क्लस्टर फिर से शुरू हो गए, और लॉग में हमने निम्नलिखित त्रुटि देखी:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

पेट्रोनी क्लस्टर अपने क्लस्टर के बारे में जानकारी प्राप्त करने में असमर्थ था और पुनः आरंभ हुआ।

समाधान खोजने के लिए, हमने जीथब पर एक अंक के माध्यम से पेट्रोनी लेखकों से संपर्क किया। उन्होंने हमारी कॉन्फ़िगरेशन फ़ाइलों में सुधार का सुझाव दिया:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

हम समस्या को परीक्षण परिवेश में दोहराने में सक्षम थे और वहां इन विकल्पों का परीक्षण किया, लेकिन दुर्भाग्य से वे काम नहीं कर सके।

समस्या अभी भी अनसुलझी है. हम निम्नलिखित समाधान आज़माने की योजना बना रहे हैं:

प्रत्येक पेट्रोनी क्लस्टर उदाहरण पर कंसल-एजेंट का उपयोग करें;
कोड में समस्या ठीक करें.

हम समझते हैं कि त्रुटि कहाँ हुई: समस्या संभवतः डिफ़ॉल्ट टाइमआउट का उपयोग है, जिसे कॉन्फ़िगरेशन फ़ाइल के माध्यम से ओवरराइड नहीं किया गया है। जब अंतिम कॉन्सल सर्वर को क्लस्टर से हटा दिया जाता है, तो पूरा कॉन्सल क्लस्टर एक सेकंड से अधिक समय तक रुक जाता है, इस वजह से, पेट्रोनी क्लस्टर की स्थिति प्राप्त नहीं कर पाता है और पूरे क्लस्टर को पूरी तरह से पुनरारंभ कर देता है।

सौभाग्य से, हमें और कोई त्रुटि नहीं मिली।

पेट्रोनी का उपयोग करने के परिणाम

पेट्रोनी के सफल प्रक्षेपण के बाद, हमने प्रत्येक क्लस्टर में एक अतिरिक्त प्रतिकृति जोड़ी। अब प्रत्येक क्लस्टर में एक कोरम की झलक होती है: स्विच करते समय विभाजन-मस्तिष्क के मामले में सुरक्षा जाल के लिए एक नेता और दो प्रतिकृतियां।

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

पेट्रोनी के उपयोग का एक छोटा सा सारांश:

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

स्रोत: www.habr.com

फ़ेलओवर क्लस्टर PostgreSQL + पेट्रोनी। कार्यान्वयन का अनुभव