🥇 विफलता क्लस्टर PostgreSQL + Patroni। कार्यान्वयन अनुभव

यस लेखमा म तपाईलाई बताउनेछु कि हामीले कसरी PostgreSQL दोष सहिष्णुताको मुद्दामा पुग्यौं, किन यो हाम्रो लागि महत्त्वपूर्ण भयो, र अन्तमा के भयो।

हामीसँग अत्यधिक लोड गरिएको सेवा छ: विश्वव्यापी 2,5 मिलियन प्रयोगकर्ताहरू, हरेक दिन 50K+ सक्रिय प्रयोगकर्ताहरू। सर्भरहरू आयरल्याण्डको एउटा क्षेत्रमा अमाजोनमा अवस्थित छन्: १००+ विभिन्न सर्भरहरू निरन्तर सञ्चालनमा छन्, तीमध्ये लगभग ५० डाटाबेसहरू छन्।

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

हामीले किन Redis बाट PostgreSQL मा स्विच गर्यौं

प्रारम्भमा, हाम्रो सेवाले Redis सँग काम गर्‍यो, एक प्रमुख-मान भण्डारण जसले सर्भरको RAM मा सबै डाटा भण्डारण गर्दछ।

रेडिसका फाइदाहरू:

उच्च प्रतिक्रिया गति, किनभने सबै कुरा मेमोरीमा भण्डार गरिएको छ;
सुविधाजनक ब्याकअप र प्रतिकृति।

हाम्रो लागि Redis को हानि:

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

हामीले बेफाइदाहरूलाई ध्यानमा राख्यौं र महसुस गर्यौं कि हामीले सामान्य लेनदेनहरू र विलम्बतामा कम निर्भरताको साथ, अझ सुविधाजनक कुरामा जान आवश्यक छ। हामीले हाम्रो अनुसन्धान गर्यौं, धेरै विकल्पहरूको विश्लेषण गर्यौं र PostgreSQL रोज्यौं।

हामी अहिले 1,5 वर्षको लागि नयाँ डाटाबेसमा सर्दै छौँ र डाटाको सानो अंश मात्र स्थानान्तरण गरेका छौं, त्यसैले अब हामी Redis र PostgreSQL सँगसँगै काम गरिरहेका छौं। डाटाबेसहरू बीच डाटा सार्ने र स्विच गर्ने चरणहरूको बारेमा थप जानकारी लेखिएको छ मेरो सहकर्मी द्वारा लेख.

जब हामीले पहिलो पटक सार्न थाल्यौं, हाम्रो अनुप्रयोगले सीधा डाटाबेससँग काम गर्‍यो र Redis र PostgreSQL मास्टर पहुँच गर्‍यो। PostgreSQL क्लस्टरमा मास्टर र एसिन्क्रोनस प्रतिकृतिको साथ एक प्रतिकृति समावेश थियो। यो डाटाबेस कार्यप्रवाह जस्तो देखिन्छ:

PgBouncer लागू गर्दै

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

हामीसँग जडान प्रबन्धकको लागि दुई विकल्पहरू थिए: Pgpool र PgBouncer। तर पहिलोले डाटाबेससँग काम गर्ने लेनदेन मोडलाई समर्थन गर्दैन, त्यसैले हामीले PgBouncer रोज्यौं।

हामीले निम्न कार्य योजना कन्फिगर गरेका छौं: हाम्रो अनुप्रयोगले एउटा PgBouncer पहुँच गर्छ, जसको पछाडि PostgreSQL मास्टरहरू छन्, र प्रत्येक मास्टरको पछाडि एसिन्क्रोनस प्रतिकृतिको साथ एउटा प्रतिकृति छ।

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

PgBouncer दोष सहिष्णुता

यो योजनाले मात्र PgBouncer उदाहरणको मृत्यु नभएसम्म काम गर्यो। हामी AWS मा छौं, जहाँ आवधिक रूपमा मर्ने हार्डवेयरमा सबै उदाहरणहरू लन्च हुन्छन्। यस्तो अवस्थामा, उदाहरण मात्र नयाँ हार्डवेयरमा सर्छ र फेरि काम गर्दछ। यो PgBouncer संग भयो, तर यो अनुपलब्ध भयो। यो दुर्घटनाको परिणाम हाम्रो सेवा 25 मिनेटको लागि अनुपलब्ध थियो। त्यस्ता परिस्थितिहरूको लागि, AWS ले प्रयोगकर्ता पक्षमा रिडन्डन्सी प्रयोग गर्न सिफारिस गर्दछ, जुन हामीले त्यस समयमा लागू गरेका थिएनौं।

त्यस पछि, हामीले PgBouncer र PostgreSQL क्लस्टरहरूको गल्ती सहिष्णुताको बारेमा गम्भीरताका साथ सोच्यौं, किनभने हाम्रो AWS खातामा कुनै पनि उदाहरणमा यस्तै अवस्था फेरि हुन सक्छ।

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

यो योजनाले तपाईंलाई सजिलैसँग नयाँ PgBouncer सर्भरहरू थप्न अनुमति दिन्छ।

PostgreSQL फेलओभर क्लस्टर सिर्जना गर्दै

यो समस्या समाधान गर्दा, हामीले विभिन्न विकल्पहरू विचार गर्यौं: स्व-लिखित फेलओभर, repmgr, AWS RDS, Patroni।

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

तिनीहरूले मास्टरको कामको निगरानी गर्न सक्छन् र, यदि यो असफल भएमा, प्रतिकृतिलाई मास्टरमा प्रवर्द्धन गर्न र PgBouncer कन्फिगरेसन अपडेट गर्न सक्छ।

यस दृष्टिकोणको फाइदाहरू अधिकतम सरलता हुन्, किनभने तपाईंले स्क्रिप्टहरू आफैं लेख्नुहुन्छ र तिनीहरूले कसरी काम गर्छन् भन्ने कुरा बुझ्नुहुन्छ।

Cons:

मास्टरको मृत्यु नहुन सक्छ; यसको सट्टा, त्यहाँ नेटवर्क विफलता भएको हुन सक्छ। फेलओभर, यस बारे अनजानले, प्रतिकृतिलाई मास्टरमा बढावा दिनेछ, र पुरानो मास्टरले काम गर्न जारी राख्नेछ। नतिजाको रूपमा, हामीले मास्टर रोलमा दुईवटा सर्भरहरू पाउनेछौं र ती मध्ये कुनको हालको डाटा छ भनेर थाहा हुँदैन। यस अवस्थालाई स्प्लिट-ब्रेन पनि भनिन्छ;
हामी कुनै प्रतिक्रिया बिना नै छोड्यौं। हाम्रो कन्फिगरेसनमा एक मास्टर र एउटा प्रतिकृति छ, स्विच गरेपछि प्रतिकृतिलाई मास्टरमा बढावा दिइन्छ र हामीसँग अब प्रतिकृतिहरू छैनन्, त्यसैले हामीले म्यानुअल रूपमा नयाँ प्रतिकृति थप्नु पर्छ;
हामीलाई फेलओभर अपरेशनको अतिरिक्त निगरानी चाहिन्छ, र हामीसँग १२ PostgreSQL शार्डहरू छन्, जसको मतलब हामीले १२ क्लस्टरहरू निगरानी गर्न आवश्यक छ। शार्डहरूको संख्या बढाउँदा, तपाईंले फेलओभर अपडेट गर्न पनि सम्झनुपर्छ।

एक स्व-लिखित फेलओभर धेरै जटिल देखिन्छ र गैर-तुच्छ समर्थन चाहिन्छ। एउटा PostgreSQL क्लस्टरको साथ, यो सबैभन्दा सरल विकल्प हुनेछ, तर यसले मापन गर्दैन, त्यसैले यो हाम्रो लागि उपयुक्त छैन।

Repmgr

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

AWS RDS

यसले हामीलाई चाहिने सबै कुरालाई समर्थन गर्दछ, ब्याकअप गर्न सक्छ र जडानहरूको पूललाई समर्थन गर्दछ। यसमा स्वचालित स्विचिङ छ: जब मास्टरको मृत्यु हुन्छ, प्रतिकृति नयाँ मास्टर बन्छ, र AWS ले DNS रेकर्डलाई नयाँ मास्टरमा परिवर्तन गर्दछ, जबकि प्रतिकृतिहरू विभिन्न AZ मा अवस्थित हुन सक्छन्।

बेफाइदाहरूमा राम्रो सेटिङहरूको कमी समावेश छ। फाइन-ट्यूनिङको उदाहरणको रूपमा: हाम्रो उदाहरणहरूमा tcp जडानहरूका लागि प्रतिबन्धहरू छन्, जुन दुर्भाग्यवश, RDS मा गर्न सकिँदैन:

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 नियमित उदाहरण मूल्यको तुलनामा लगभग दोब्बर महँगो छ, जुन यो समाधान त्याग्ने मुख्य कारण थियो।

संरक्षक

यो राम्रो कागजात, स्वचालित विफलता र github मा स्रोत कोड संग PostgreSQL प्रबन्ध गर्न को लागी एक पाइथन टेम्प्लेट हो।

Patroni को लाभ:

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

Cons:

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

फलस्वरूप, हामीले फेलओभर क्लस्टर सिर्जना गर्न Patroni रोज्यौं।

संरक्षक कार्यान्वयन प्रक्रिया

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

Patroni लागू गर्न, हामीले वितरित क्लस्टर कन्फिगरेसन भण्डारण चयन गर्न आवश्यक छ। Patroni वितरित कन्फिगरेसन भण्डारण प्रणालीहरू जस्तै etcd, Zookeeper, Consul सँग काम गर्दछ। हामीसँग उत्पादनमा पूर्ण कन्सुल क्लस्टर छ, जसले Vault सँग संयोजनमा काम गर्छ र हामी यसलाई अब प्रयोग गर्दैनौं। यसको अभिप्रेत उद्देश्यको लागि कन्सुल प्रयोग गर्न सुरु गर्ने एउटा ठूलो कारण।

Patroni कन्सुलसँग कसरी काम गर्दछ

हामीसँग कन्सुल क्लस्टर छ, जसमा तीनवटा नोडहरू हुन्छन्, र एउटा Patroni क्लस्टर, जसमा नेता र प्रतिकृति हुन्छ (पट्रोनीमा, मालिकलाई क्लस्टर नेता भनिन्छ, र दासहरूलाई प्रतिकृति भनिन्छ)। प्रत्येक Patroni क्लस्टर उदाहरणले लगातार क्लस्टरको अवस्था बारे कन्सुललाई जानकारी पठाउँछ। तसर्थ, कन्सुलबाट तपाईले जहिले पनि Patroni क्लस्टरको हालको कन्फिगरेसन पत्ता लगाउन सक्नुहुन्छ र अहिलेको नेता को हो।

Patroni लाई कन्सुलसँग जोड्नको लागि, केवल आधिकारिक कागजातहरू अध्ययन गर्नुहोस्, जसमा भनिएको छ कि हामीले कन्सुलसँग कसरी काम गर्छौं, र जडान रेखाचित्र, वैकल्पिक रूपमा, तपाइँले 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 }}

तर त्यो तरिकाले काम गर्दैन। स्टार्टअपमा, Patroni कन्सुलसँग जडान हुन सक्दैन किनभने यसले अझै पनि http मार्फत जाने प्रयास गर्छ।

Patroni स्रोत कोडले समस्या समाधान गर्न मद्दत गर्यो। यो पाइथन मा लेखिएको राम्रो छ। यो बाहिर जान्छ कि होस्ट प्यारामिटर कुनै पनि तरिकामा पार्स गरिएको छैन, र प्रोटोकल योजना मा निर्दिष्ट हुनुपर्छ। कन्सुलसँग काम गर्ने कार्य कन्फिगरेसन ब्लक हाम्रो लागि यस्तो देखिन्छ:

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

कन्सुल टेम्प्लेट

त्यसैले, हामीले कन्फिगरेसन भण्डारण छनौट गरेका छौं। अब हामीले बुझ्नु आवश्यक छ कि कसरी PgBouncer ले यसको कन्फिगरेसन बदल्छ जब Patroni क्लस्टरमा नेता परिवर्तन हुन्छ। कागजातमा यस प्रश्नको कुनै जवाफ छैन, किनकि ... सिद्धान्तमा, PgBouncer सँग काम गर्ने त्यहाँ वर्णन गरिएको छैन।

समाधानको खोजीमा, हामीले एउटा लेख फेला पार्‍यौं (दुर्भाग्यवश, मलाई नाम याद छैन), जहाँ यो लेखिएको थियो कि कन्सुल-टेम्प्लेट PgBouncer र Patroni को संयोजन गर्न धेरै उपयोगी थियो। यसले हामीलाई कन्सुल-टेम्प्लेटको काम अध्ययन गर्न प्रेरित गर्‍यो।

कन्सुल-टेम्प्लेटले कन्सुलमा PostgreSQL क्लस्टरको कन्फिगरेसनलाई निरन्तर निगरानी गर्छ भन्ने कुरा बाहिर आयो। जब नेता परिवर्तन हुन्छ, यसले PgBouncer कन्फिगरेसन अपडेट गर्छ र यसलाई पुन: लोड गर्न आदेश पठाउँछ।

टेम्प्लेटको ठूलो फाइदा यो हो कि यो कोडको रूपमा भण्डारण गरिएको छ, त्यसैले नयाँ शार्ड थप्दा, यो कोड सिद्धान्तको रूपमा पूर्वाधारलाई समर्थन गर्दै, नयाँ कमिट बनाउन र टेम्प्लेट स्वचालित रूपमा अपडेट गर्न पर्याप्त छ।

Patroni संग नयाँ वास्तुकला

नतिजाको रूपमा, हामीले निम्न कार्य योजना प्राप्त गर्यौं:

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

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

यसलाई उत्पादनमा लन्च गर्नु अघि, हामीले यो योजनालाई सानो परीक्षण वातावरणमा लन्च गर्यौं र स्वचालित स्विचिङको सञ्चालन जाँच गर्यौं। तिनीहरूले बोर्ड खोले, स्टिकर सारे र त्यस क्षणमा क्लस्टरको नेतालाई "मार्यो"। AWS मा, तपाईले गर्नुपर्ने भनेको कन्सोल मार्फत उदाहरण बन्द गर्नु हो।

स्टिकर 10-20 सेकेन्ड भित्र फर्कियो, र त्यसपछि फेरि सामान्य रूपमा सार्न थाल्यो। यसको मतलब यो हो कि Patroni क्लस्टरले सही रूपमा काम गर्यो: यसले नेता परिवर्तन गर्यो, कन्सुललाई जानकारी पठायो, र कन्सुल-टेम्प्लेटले तुरुन्तै यो जानकारी उठायो, PgBouncer कन्फिगरेसनलाई बदल्यो र पुन: लोड गर्न आदेश पठायो।

कसरी उच्च लोड अन्तर्गत बाँच्ने र न्यूनतम डाउनटाइम कायम राख्ने?

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

हामीले लोड परीक्षण सञ्चालन गर्ने परीक्षण वातावरणले हामीलाई पहिलो प्रश्नको जवाफ दिन मद्दत गर्छ। यो वास्तुकलामा उत्पादनसँग पूर्ण रूपमा समान छ र परीक्षण डेटा उत्पन्न गरेको छ, जुन उत्पादनको मात्रामा लगभग बराबर छ। हामी परीक्षणको क्रममा PostgreSQL मास्टरहरू मध्ये एकलाई "मार" गर्ने निर्णय गर्छौं र के हुन्छ हेर्नुहोस्। तर त्यो भन्दा पहिले, स्वचालित रोलआउट जाँच गर्न महत्त्वपूर्ण छ, किनकि यस वातावरणमा हामीसँग धेरै PostgreSQL शार्डहरू छन्, त्यसैले हामीले उत्पादन अघि कन्फिगरेसन लिपिहरूको उत्कृष्ट परीक्षण प्राप्त गर्नेछौं।

दुबै कार्यहरू महत्वाकांक्षी देखिन्छन्, तर हामीसँग PostgreSQL 9.6 छ। सायद हामी तुरुन्तै 11.2 मा अपडेट गर्न सक्छौं?

हामी यसलाई २ चरणहरूमा गर्ने निर्णय गर्छौं: पहिले संस्करण ११.२ मा अपडेट गर्नुहोस्, त्यसपछि Patroni सुरु गर्नुहोस्।

PostgreSQL अद्यावधिक

PostgreSQL संस्करण चाँडै अपडेट गर्न, तपाईंले विकल्प प्रयोग गर्नुपर्छ -k, जसमा डिस्कमा हार्ड लिङ्क सिर्जना गरिएको छ र तपाईंको डाटा प्रतिलिपि गर्न आवश्यक छैन। 300-400 GB को डाटाबेसहरूमा, अपडेटले 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 सेकेन्डमा पूरा भयो, जुन उत्कृष्ट परिणाम हो।

Patroni को शुभारम्भ

दोस्रो समस्या समाधान गर्न, केवल Patroni कन्फिगरेसन हेर्नुहोस्। आधिकारिक भण्डारमा initdb सँग एउटा उदाहरण कन्फिगरेसन छ, जुन Patroni लाई पहिलो पटक सुरु गर्दा नयाँ डाटाबेस प्रारम्भ गर्न जिम्मेवार हुन्छ। तर हामीसँग पहिले नै तयार डाटाबेस भएकोले, हामीले कन्फिगरेसनबाट मात्र यो खण्ड हटायौं।

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

rm -rf /var/lib/postgresql/

यो दास मा मात्र गर्नुपर्छ!

सफा प्रतिकृति जडान गर्दा, Patroni ले बेसब्याकअप लिडर बनाउँछ र यसलाई प्रतिकृतिमा पुनर्स्थापना गर्छ, र त्यसपछि वाल लगहरू प्रयोग गरेर हालको अवस्थालाई समात्छ।

हामीले सामना गरेको अर्को कठिनाई भनेको सबै PostgreSQL क्लस्टरहरूलाई पूर्वनिर्धारित रूपमा मुख्य भनिन्छ। जब प्रत्येक क्लस्टरलाई अर्कोको बारेमा केही थाहा हुँदैन, यो सामान्य हो। तर जब तपाइँ Patroni प्रयोग गर्न चाहानुहुन्छ, सबै क्लस्टरहरूको एक अद्वितीय नाम हुनुपर्छ। समाधान PostgreSQL कन्फिगरेसनमा क्लस्टर नाम परिवर्तन गर्नु हो।

लोड परीक्षण

हामीले बोर्डमा प्रयोगकर्ताहरूले कसरी काम गर्छन् भन्ने अनुकरण गर्ने एउटा परीक्षण सुरु गर्‍यौं। जब लोड हाम्रो दैनिक औसतमा पुग्यो, हामीले ठ्याक्कै उही परीक्षण दोहोर्यायौं, हामीले नेता PostgreSQL सँग एउटा उदाहरण बन्द गर्यौं। स्वचालित फेलओभरले हामीले अपेक्षा गरे अनुसार काम गर्‍यो: Patroni ले नेता परिवर्तन गर्‍यो, कन्सुल-टेम्प्लेटले PgBouncer कन्फिगरेसन अपडेट गर्‍यो र पुन: लोड गर्न आदेश पठायो। Grafana मा हाम्रो ग्राफ अनुसार, यो स्पष्ट थियो कि त्यहाँ 20-30 सेकेन्डको ढिलाइ र डाटाबेसमा जडान सम्बन्धित सर्भरबाट त्रुटिहरूको सानो मात्रा थियो। यो एक सामान्य अवस्था हो, त्यस्ता मानहरू हाम्रो फेलओभरको लागि स्वीकार्य छन् र निश्चित रूपमा सेवा डाउनटाइम भन्दा राम्रो छन्।

उत्पादनमा Patroni को सुरुवात

नतिजाको रूपमा, हामीले निम्न योजनाको साथ आएका छौं:

PgBouncer सर्भरमा कन्सुल-टेम्प्लेट प्रयोग गर्नुहोस् र सुरुवात गर्नुहोस्;
PostgreSQL संस्करण 11.2 मा अद्यावधिकहरू;
क्लस्टर नाम परिवर्तन गर्दै;
Patroni क्लस्टर को शुभारम्भ।

एकै समयमा, हाम्रो योजनाले हामीलाई लगभग कुनै पनि समयमा पहिलो बिन्दु गर्न अनुमति दिन्छ; हामी प्रत्येक PgBouncer लाई एक एक गरेर कामबाट हटाउन सक्छौं र त्यसमा कन्सुल-टेम्प्लेटको प्रयोग र सुरुवात गर्न सक्छौं। हामीले त्यही गर्यौं।

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

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

हामीले हाम्रो सेवा पुन: सुरु गर्यौं, सबै कुराले जस्तै काम गर्यो, प्रयोगकर्ताहरूले काम गर्न जारी राखे, तर ग्राफहरूमा हामीले कन्सुल सर्भरहरूमा असामान्य रूपमा उच्च लोड देख्यौं।

हामीले परीक्षणको वातावरणमा यो किन देखेनौं? यो समस्याले पूर्वाधारलाई कोड सिद्धान्तको रूपमा पालना गर्न र परीक्षण वातावरणदेखि उत्पादनसम्म सम्पूर्ण पूर्वाधार सुधार गर्न आवश्यक छ भनी राम्रोसँग चित्रण गर्दछ। अन्यथा, हामीले पाएको समस्या प्राप्त गर्न धेरै सजिलो छ। के भयो? कन्सुल पहिले उत्पादनमा देखा पर्‍यो, र त्यसपछि परीक्षण वातावरणमा; नतिजाको रूपमा, परीक्षण वातावरणमा कन्सुलको संस्करण उत्पादनमा भन्दा उच्च थियो। केवल एक विज्ञप्ति मा, कन्सुल-टेम्प्लेट संग काम गर्दा एक CPU लीक हल भयो। त्यसैले हामीले कन्सुललाई मात्र अपडेट गर्यौं, यसरी समस्या समाधान भयो।

Patroni क्लस्टर पुन: सुरु गर्नुहोस्

यद्यपि, हामीले एउटा नयाँ समस्या पायौं जसको बारेमा हामीले शंका पनि गरेका थिएनौं। Consul अद्यावधिक गर्दा, हामी कन्सुल छोड्ने आदेश → Patroni अर्को कन्सुल सर्भरमा जडान → सबै काम गर्दछ प्रयोग गरेर क्लस्टरबाट कन्सुल नोड हटाउँछौं। तर जब हामी कन्सुल क्लस्टरको अन्तिम उदाहरणमा पुग्यौं र यसलाई कन्सुल छुट्टी आदेश पठायौं, सबै Patroni क्लस्टरहरू मात्र पुन: सुरु भयो, र लगहरूमा हामीले निम्न त्रुटि देख्यौं:

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>

Patroni क्लस्टर आफ्नो क्लस्टर बारे जानकारी प्राप्त गर्न असमर्थ थियो र पुन: सुरु भयो।

समाधान खोज्नको लागि, हामीले Github मा एक मुद्दा मार्फत Patroni को लेखकहरु लाई सम्पर्क गर्यौं। तिनीहरूले हाम्रो कन्फिगरेसन फाइलहरूमा सुधारहरू सुझाव दिए:

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

हामीले परीक्षण वातावरणमा मुद्दा दोहोर्याउन सक्षम थियौं र त्यहाँ यी सेटिङहरू परीक्षण गर्‍यौं, तर दुर्भाग्यवश तिनीहरूले काम गरेनन्।

समस्या अझै समाधान हुन सकेको छैन । हामी निम्न समाधानहरू प्रयास गर्ने योजना बनाउँछौं:

Patroni क्लस्टरको प्रत्येक उदाहरणमा कन्सुल-एजेन्ट प्रयोग गर्नुहोस्;
कोडमा समस्या समाधान गर्नुहोस्।

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

सौभाग्यवश, हामीले कुनै पनि थप त्रुटिहरू सामना गरेनौं।

Patroni प्रयोग गर्ने परिणामहरू

Patroni को सफल प्रक्षेपण पछि, हामीले प्रत्येक क्लस्टरमा थप प्रतिकृति थप्यौं। अब प्रत्येक क्लस्टरमा कोरमको झलक छ: एक नेता र दुई प्रतिकृतिहरू, स्विच गर्दा स्प्लिट-ब्रेनबाट जोगाउन।

संरक्षकले तीन महिनाभन्दा बढी समयदेखि उत्पादनमा काम गरिरहेको छ । यस समयमा, उहाँले पहिले नै हामीलाई मद्दत गर्न व्यवस्थित गर्नुभयो। भर्खरै, AWS मा एक क्लस्टरको नेताको मृत्यु भयो, स्वचालित फेलओभरले काम गर्यो र प्रयोगकर्ताहरूले काम गर्न जारी राखे। संरक्षकले आफ्नो मुख्य काम पूरा गरेको छ।

Patroni प्रयोग गर्ने छोटो सारांश:

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

स्रोत: www.habr.com

फेलओभर क्लस्टर PostgreSQL + Patroni। कार्यान्वयन अनुभव