Patroni असफलता कथाहरू वा तपाईंको PostgreSQL क्लस्टर कसरी क्र्यास गर्ने। एलेक्सी लेसोव्स्की

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

म तिमीलाई आफ्नो बारेमा थोरै बताउँछु। मैले प्रणाली प्रशासकको रूपमा सुरु गरें। वेब विकास मा काम गरे। म 2014 देखि Data Egret मा काम गरिरहेको छु। कम्पनी Postgres को क्षेत्र मा परामर्श मा संलग्न छ। र हामी ठ्याक्कै Postgres सेवा गर्छौं, र हामी हरेक दिन Postgres सँग काम गर्छौं, त्यसैले हामीसँग सञ्चालनसँग सम्बन्धित विभिन्न विशेषज्ञताहरू छन्।

र 2018 को अन्त्यमा, हामीले बिस्तारै Patroni प्रयोग गर्न थाल्यौं। र केहि अनुभव संचित भएको छ। हामीले यसलाई कुनै न कुनै रूपमा निदान गर्यौं, यसलाई ट्युन गर्‍यौं, हाम्रो उत्कृष्ट अभ्यासहरूमा आएका छौं। र यस रिपोर्टमा म तिनीहरूको बारेमा कुरा गर्नेछु।

Postgres बाहेक, मलाई लिनक्स मन पर्छ। मलाई यसमा घुम्न र अन्वेषण गर्न मन पर्छ, म कोरहरू सङ्कलन गर्न चाहन्छु। मलाई भर्चुअलाइजेशन, कन्टेनर, डकर, कुबर्नेट्स मन पर्छ। यो सबै मलाई चासो छ, किनकि पुरानो प्रशासक बानीहरु असर गर्दै छन्। मलाई अनुगमन गर्न मनपर्छ। र मलाई प्रशासनसँग सम्बन्धित पोस्टग्रेस चीजहरू मनपर्छ, जस्तै प्रतिकृति, ब्याकअप। र मेरो फुर्सदको समयमा म Go मा लेख्छु। म सफ्टवेयर इन्जिनियर होइन, म गो मा आफ्नो लागि मात्र लेख्छु। र यसले मलाई आनन्द दिन्छ।

• मलाई लाग्छ तपाईं मध्ये धेरैलाई थाहा छ कि Postgres सँग HA (उच्च उपलब्धता) बाकस बाहिर छैन। HA प्राप्त गर्न, तपाईंले केहि स्थापना गर्न आवश्यक छ, यसलाई कन्फिगर गर्नुहोस्, प्रयास गर्नुहोस् र यसलाई प्राप्त गर्नुहोस्।
• त्यहाँ धेरै उपकरणहरू छन् र Patroni ती मध्ये एक हो जसले HA धेरै राम्रो र राम्रोसँग समाधान गर्दछ। तर यो सबैलाई परीक्षण प्रयोगशालामा राखेर र यसलाई चलाएर, हामी देख्न सक्छौं कि यो सबै काम गर्दछ, हामी केहि समस्याहरू पुन: उत्पादन गर्न सक्छौं, Patroni कसरी सेवा गर्दछ हेर्नुहोस्। र हामी देख्नेछौं कि यो सबै राम्रो काम गर्दछ।
• तर व्यवहारमा हामीले विभिन्न समस्याको सामना गर्नुपरेको छ । र म यी समस्याहरूको बारेमा कुरा गर्नेछु।
• म तपाईलाई बताउनेछु कि हामीले यसलाई कसरी निदान गर्यौं, हामीले के ट्वीक गर्यौं - यसले हामीलाई मद्दत गर्यो वा होइन।

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

र हामीले हाम्रो रिपोर्ट सुरु गर्नु अघि एउटा सानो अस्वीकरण।

यी सबै समस्याहरू जुन हामीले सामना गरेका थियौं, हामीले तिनीहरू सञ्चालनको पहिलो 6-7-8 महिनामा भोग्यौं। समयको साथ, हामी हाम्रो आन्तरिक उत्कृष्ट अभ्यासहरूमा आयौं। र हाम्रा समस्याहरू हराए। त्यसकारण, प्रतिवेदन लगभग छ महिना अघि घोषणा गरिएको थियो, जब यो मेरो दिमागमा ताजा थियो र मैले यो सबै राम्ररी याद गरें।

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

Patroni के हो?

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

र एउटा सानो नतिजा यो हो कि Patroni को मुख्य कार्य एक अटोफाइल राम्रो र भरपर्दो तरिकाले गर्नु हो ताकि हाम्रो क्लस्टर सञ्चालनमा रहन्छ र अनुप्रयोगले क्लस्टर टोपोलोजीमा परिवर्तनहरू याद गर्दैन।

तर जब हामी Patroni प्रयोग गर्न थाल्छौं, हाम्रो प्रणाली अलि बढी जटिल हुन्छ। यदि पहिले हामीसँग Postgres थियो भने, तब Patroni प्रयोग गर्दा हामी Patroni आफै पाउँछौं, हामीले DCS पाउँछौं जहाँ राज्य भण्डारण हुन्छ। र यो सबै कुनै न कुनै रूपमा काम गर्नुपर्छ। त्यसोभए के गलत हुन सक्छ?

तोड्न सक्छ:

• Postgres बिग्रन सक्छ। यो एक मास्टर वा प्रतिकृति हुन सक्छ, ती मध्ये एक असफल हुन सक्छ।
• संरक्षक आफै टुट्न सक्छ।
• DCS जहाँ राज्य भण्डारण गरिएको छ तोड्न सक्छ।
• र नेटवर्क तोड्न सक्छ।

यी सबै बुँदाहरू म प्रतिवेदनमा विचार गर्नेछु।

म केसहरूलाई विचार गर्नेछु किनकि तिनीहरू थप जटिल हुन्छन्, मुद्दामा धेरै घटकहरू समावेश छन् भन्ने दृष्टिकोणबाट होइन। र व्यक्तिपरक भावनाहरूको दृष्टिकोणबाट, कि यो केस मेरो लागि गाह्रो थियो, यसलाई अलग गर्न गाह्रो थियो ... र यसको विपरीत, केहि केस हल्का थियो र यसलाई अलग गर्न सजिलो थियो।

र पहिलो मामला सबै भन्दा सजिलो छ। यो अवस्था हो जब हामीले डाटाबेस क्लस्टर लियौं र एउटै क्लस्टरमा हाम्रो DCS भण्डारण तैनात गर्यौं। यो सबैभन्दा सामान्य गल्ती हो। यो आर्किटेक्चर निर्माणमा गल्ती हो, अर्थात्, एकै ठाउँमा विभिन्न कम्पोनेन्टहरू मिलाएर।

त्यसोभए, त्यहाँ एक फाइलर थियो, के भयो त्यसको समाधान गर्न जाऔं।

र यहाँ हामी चासो राख्छौं जब फाइलर भयो। त्यो हो, हामी यस क्षणमा चासो राख्छौं जब क्लस्टर राज्य परिवर्तन भयो।

तर फाइलर सधैं तात्कालिक हुँदैन, अर्थात् यसले समयको कुनै एकाइ लिदैन, यो ढिलाइ हुन सक्छ। यो लामो समय सम्म रहन सक्छ।

त्यसकारण, यसको सुरुवात समय र अन्त्य समय छ, अर्थात् यो निरन्तर घटना हो। र हामी सबै घटनाहरूलाई तीन अन्तरालहरूमा विभाजन गर्छौं: हामीसँग फाइलर अघि, फाइलरको समयमा र फाइलर पछि समय छ। त्यो हो, हामी यस टाइमलाइनमा सबै घटनाहरू विचार गर्छौं।

र पहिलो कुरा, जब फाइलर भयो, हामी के भयो त्यसको कारण खोज्छौं, फाइलरको कारण के थियो।

यदि हामीले लगहरू हेर्‍यौं भने, तिनीहरू क्लासिक Patroni लगहरू हुनेछन्। उसले हामीलाई बताउँछ कि सर्भर मास्टर भएको छ, र मास्टरको भूमिका यस नोडमा पारित भएको छ। यहाँ हाइलाइट गरिएको छ।

अर्को, हामीले बुझ्नुपर्छ कि फाइलर किन भयो, अर्थात् कुन घटनाहरू भयो जसले मास्टर रोललाई एक नोडबाट अर्कोमा सार्नको कारण भयो। र यस अवस्थामा, सबै कुरा सरल छ। हामीसँग भण्डारण प्रणालीसँग अन्तरक्रिया गर्दा त्रुटि छ। मास्टरले महसुस गरे कि उसले DCS सँग काम गर्न सक्दैन, अर्थात्, अन्तरक्रियामा केहि प्रकारको समस्या थियो। र उनी अब मास्टर हुन नसक्ने र राजीनामा दिन्छन्। यो रेखा "डिमोटेड सेल्फ" ले ठ्याक्कै त्यही भन्छ।

यदि हामीले फाइलर अघिका घटनाहरूलाई हेर्छौं भने, हामी त्यहाँ विजार्डको निरन्तरताको लागि समस्या भएका कारणहरू देख्न सक्छौं।

यदि हामीले Patroni लगहरू हेर्‍यौं भने, हामी देख्नेछौं कि हामीसँग धेरै त्रुटिहरू छन्, टाइमआउटहरू छन्, अर्थात् Patroni एजेन्टले DCS सँग काम गर्न सक्दैन। यस अवस्थामा, यो कन्सुल एजेन्ट हो, जसले पोर्ट 8500 मा सञ्चार गरिरहेको छ।

र यहाँ समस्या यो हो कि Patroni र डाटाबेस एउटै होस्टमा चलिरहेको छ। र कन्सुल सर्भरहरू एउटै नोडमा सुरू गरियो। सर्भरमा लोड सिर्जना गरेर, हामीले कन्सुल सर्भरहरूको लागि पनि समस्याहरू सिर्जना गर्यौं। उनीहरूले राम्ररी सञ्चार गर्न सकेनन्।

केही समय पछि, जब लोड कम भयो, हाम्रो संरक्षकले फेरि एजेन्टहरूसँग कुराकानी गर्न सक्षम भए। सामान्य काम फेरि सुरु भयो। र उही Pgdb-2 सर्भर फेरि मास्टर भयो। त्यो हो, त्यहाँ एक सानो फ्लिप थियो, जसको कारण नोडले मास्टरको शक्तिलाई इस्तीफा दियो, र त्यसपछि तिनीहरूलाई फेरि लियो, त्यो हो, सबै कुरा जस्तै फर्कियो।

र यो एक गलत अलार्म मान्न सकिन्छ, वा यो Patroni सबै ठीक गर्यो भनेर मान्न सकिन्छ। अर्थात्, उनले क्लस्टरको अवस्था कायम राख्न नसक्ने महसुस गरे र आफ्नो अधिकार हटाए।

र यहाँ कन्सुल सर्भरहरू आधारहरू जस्तै हार्डवेयरमा छन् भन्ने तथ्यको कारण समस्या उत्पन्न भयो। तदनुसार, कुनै पनि लोड: चाहे यो डिस्क वा प्रोसेसरहरूमा लोड हो, यसले कन्सुल क्लस्टरसँगको अन्तरक्रियालाई पनि असर गर्छ।

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

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

पहिलो समस्या, तपाईं बुझ्नुहुन्छ, सरल छ। हामीले आधारसँग DCS लिएर राख्यौं, हामीलाई समस्या भयो।

दोस्रो समस्या पहिलो जस्तै छ। यो समान छ कि हामीसँग फेरि DCS प्रणालीसँग अन्तरक्रियात्मक समस्याहरू छन्।

यदि हामीले लगहरू हेर्‍यौं भने, हामी देख्नेछौं कि हामीसँग फेरि सञ्चार त्रुटि छ। र Patroni भन्छन् कि म DCS सँग अन्तर्क्रिया गर्न सक्दिन त्यसैले हालको मास्टर प्रतिकृति मोडमा जान्छ।

पुरानो मास्टर एक प्रतिकृति बन्छ, यहाँ Patroni काम गर्छ, यो हुनुपर्छ। यसले लेनदेन लग रिवाइन्ड गर्न pg_rewind चलाउँछ र त्यसपछि नयाँ मास्टरसँग भेट्न नयाँ मास्टरमा जडान हुन्छ। यहाँ Patroni काम गर्छ, उहाँले गर्नुपर्छ।

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

र एक सामान्य अवस्थामा, लगहरु केहि यस्तो देखिन्छ। तालाको मालिक जाँच गरिएको छ। र यदि मालिक, उदाहरणका लागि, परिवर्तन भएको छ, त्यसपछि केही घटनाहरू हुन सक्छ कि Patroni प्रतिक्रिया गर्नुपर्छ। तर यस अवस्थामा, हामी ठीक छौं। हामी त्रुटिहरू सुरु भएको ठाउँ खोजिरहेका छौं।

र त्रुटिहरू देखा पर्न थालेको बिन्दुमा स्क्रोल गरेपछि, हामी देख्छौं कि हामीसँग एक स्वत: फाइल ओभर छ। र हाम्रा त्रुटिहरू DCS सँगको अन्तरक्रियासँग सम्बन्धित भएकाले र हाम्रो मामलामा हामीले कन्सुल प्रयोग गर्यौं, हामी कन्सुल लगहरू पनि हेर्छौं, त्यहाँ के भयो।

फाइलरको समय र कन्सुल लगहरूमा रहेको समयलाई मोटे रूपमा तुलना गर्दा, हामी देख्छौं कि कन्सुल क्लस्टरमा रहेका हाम्रा छिमेकीहरूले कन्सुल क्लस्टरका अन्य सदस्यहरूको अस्तित्वमा शंका गर्न थालेका छन्।

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

यदि तपाइँ यी त्रुटिहरू अघि के भयो भनेर हेर्नुभयो भने, तपाइँ देख्न सक्नुहुन्छ कि त्यहाँ सबै प्रकारका त्रुटिहरू छन्, उदाहरणका लागि, समयसीमा, RPC घट्यो, अर्थात् कन्सुल क्लस्टर सदस्यहरूको एकअर्कासँगको अन्तरक्रियामा स्पष्ट रूपमा केहि प्रकारको समस्या छ। ।

सबैभन्दा सरल जवाफ नेटवर्क मर्मत गर्न हो। तर मलाई, मञ्चमा उभिएर, यो भन्न सजिलो छ। तर परिस्थिति यस्तो छ कि सधैं ग्राहकले नेटवर्क मर्मत गर्न खर्च गर्न सक्दैन। ऊ DC मा बस्न सक्छ र नेटवर्क मर्मत गर्न सक्षम नहुन सक्छ, उपकरणलाई असर गर्न सक्छ। र त्यसैले केहि अन्य विकल्पहरू आवश्यक छ।

त्यहाँ विकल्पहरू छन्:

• सरल विकल्प, जुन लेखिएको छ, मेरो विचारमा, कागजातमा पनि, कन्सुल चेकहरू असक्षम पार्नु हो, त्यो हो, खाली एरे पास गर्नुहोस्। र हामी कन्सुल एजेन्टलाई कुनै पनि चेक प्रयोग नगर्न भन्छौं। यी जाँचहरूको साथ, हामी यी नेटवर्क तूफानहरूलाई बेवास्ता गर्न सक्छौं र फाइलर सुरु गर्न सक्दैनौं।
• अर्को विकल्प raft_multiplier डबल जाँच गर्न हो। यो कन्सुल सर्भरको प्यारामिटर हो। पूर्वनिर्धारित रूपमा, यो 5 मा सेट गरिएको छ। यो मान स्टेजिङ वातावरणका लागि कागजातद्वारा सिफारिस गरिएको छ। वास्तवमा, यसले कन्सुल नेटवर्कका सदस्यहरू बीचको सन्देशको आवृत्तिलाई असर गर्छ। वास्तवमा, यो प्यारामिटरले कन्सुल क्लस्टरका सदस्यहरू बीचको सेवा सञ्चारको गतिलाई असर गर्छ। र उत्पादनको लागि, यो पहिले नै यसलाई कम गर्न सिफारिस गरिएको छ ताकि नोडहरू धेरै पटक सन्देशहरू आदान प्रदान गर्दछ।
• हामीले लिएर आएका अर्को विकल्प भनेको अपरेटिङ सिस्टमको प्रक्रिया अनुसूचकका लागि अन्य प्रक्रियाहरूमा कन्सुल प्रक्रियाहरूको प्राथमिकता बढाउनु हो। त्यहाँ यस्तो "राम्रो" प्यारामिटर छ, यसले केवल प्रक्रियाहरूको प्राथमिकता निर्धारण गर्दछ जुन समय तालिका बनाउँदा OS अनुसूचक द्वारा खातामा लिइन्छ। हामीले कन्सुल एजेन्टहरूका लागि राम्रो मूल्य पनि घटाएका छौं, अर्थात्। प्राथमिकता बढाएको छ ताकि अपरेटिङ सिस्टमले कन्सुल प्रक्रियाहरूलाई काम गर्न र तिनीहरूको कोड कार्यान्वयन गर्न थप समय दिन्छ। हाम्रो अवस्थामा, यसले हाम्रो समस्या समाधान गर्यो।
• अर्को विकल्प कन्सुल प्रयोग नगर्नु हो। मेरो एक साथी छ जो Etcd को ठूलो समर्थक हो। र हामी नियमित रूपमा उहाँसँग बहस गर्छौं कि कुन राम्रो Etcd वा कन्सुल। तर कुन सन्दर्भमा राम्रो छ, हामी सामान्यतया उहाँसँग सहमत छौं कि कन्सुलसँग एक एजेन्ट छ जुन डाटाबेसको साथ प्रत्येक नोडमा चलिरहेको हुनुपर्छ। त्यो हो, कन्सुल क्लस्टरसँग Patroni को अन्तरक्रिया यस एजेन्ट मार्फत जान्छ। र यो एजेन्ट एक बाधा बन्छ। यदि एजेन्टलाई केही भयो भने, तब Patroni ले कन्सुल क्लस्टरसँग काम गर्न सक्दैन। र यो समस्या हो। Etcd योजनामा ​​कुनै एजेन्ट छैन। Patroni Etcd सर्भरहरूको सूचीसँग सिधै काम गर्न सक्छ र तिनीहरूसँग पहिले नै कुराकानी गर्न सक्छ। यस सन्दर्भमा, यदि तपाइँ आफ्नो कम्पनीमा Etcd प्रयोग गर्नुहुन्छ भने, Etcd सम्भवतः कन्सुल भन्दा राम्रो विकल्प हुनेछ। तर हामी हाम्रा ग्राहकहरूमा सधैं ग्राहकले रोजेको र प्रयोग गरेको कुरामा सीमित हुन्छौं। र हामी सबै ग्राहकहरु को लागी धेरै भाग को लागी कन्सुल छ।
• र अन्तिम बिन्दु प्यारामिटर मानहरू परिमार्जन गर्न हो। हामी यी प्यारामिटरहरू माथि उठाउन सक्छौं कि हाम्रो छोटो-अवधि नेटवर्क समस्याहरू छोटो हुनेछन् र यी प्यारामिटरहरूको दायरा बाहिर नपर्नेछ। यस तरिकाले हामी Patroni को आक्रामकतालाई स्वत: फाइलमा कम गर्न सक्छौं यदि केहि नेटवर्क समस्याहरू देखा पर्छन्।

मलाई लाग्छ Patroni प्रयोग गर्ने धेरै यस आदेशसँग परिचित छन्।

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

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

यस अवस्थामा, दोस्रो प्रतिकृति मास्टर भयो। यहाँ सबै ठीक छ।

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

यस अवस्थामा, हामीसँग लेनदेन लग छैन र प्रतिकृति सुरु हुन सक्दैन। तदनुसार, हामी पोस्टग्रेसलाई त्रुटिको साथ रोक्छौं। र त्यसैले यो क्लस्टरमा छैन।

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

मैले यी घटनाहरू हुँदा टाइमस्ट्याम्पहरू तुलना गरें। र त्यहाँ फरक शाब्दिक 150 मिलिसेकेन्ड छ, त्यो हो, चेकपोइन्ट 369 मिलिसेकेन्डमा पूरा भयो, WAL खण्डहरू पुन: नामाकरण गरियो। र शाब्दिक रूपमा 517 मा, 150 मिलिसेकेन्ड पछि, पुरानो प्रतिकृतिमा रिवाइन्ड सुरु भयो। त्यो हो, शाब्दिक रूपमा 150 मिलिसेकेन्ड हाम्रो लागि पर्याप्त थियो ताकि प्रतिकृति जडान र कमाउन सकेन।

के विकल्पहरू छन्?

हामीले सुरुमा प्रतिकृति स्लटहरू प्रयोग गर्यौं। हामीले सोचेका थियौं कि यो राम्रो छ। यद्यपि सञ्चालनको पहिलो चरणमा हामीले स्लटहरू बन्द गर्यौं। यो हामीलाई लाग्थ्यो कि यदि स्लटहरूले धेरै WAL खण्डहरू जम्मा गर्छ भने, हामी मास्टर छोड्न सक्छौं। ऊ खस्नेछ। हामीले केही समय बिना स्लटहरू भोग्यौं। र हामीले महसुस गर्यौं कि हामीलाई स्लटहरू चाहिन्छ, हामीले स्लटहरू फर्कायौं।

तर यहाँ एउटा समस्या छ, कि जब मास्टर प्रतिकृतिमा जान्छ, यसले स्लटहरू मेटाउँछ र स्लटहरूसँगै WAL खण्डहरू मेटाउँछ। र यो समस्या हटाउन, हामीले wal_keep_segments प्यारामिटर बढाउने निर्णय गर्यौं। यो 8 खण्डहरूमा पूर्वनिर्धारित छ। हामीले यसलाई 1 मा बढायौं र हामीसँग कति खाली ठाउँ छ भनेर हेर्यौं। र हामीले wal_keep_segments को लागि 000 gigabytes दान गर्यौं। त्यो हो, स्विच गर्दा, हामीसँग सँधै सबै नोडहरूमा 16 गीगाबाइट लेनदेन लगहरूको रिजर्भ हुन्छ।

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

हामीसँग उत्पादनको आधार छ। त्यहाँ पहिले नै परियोजनाहरू प्रगतिमा छन्।

त्यहाँ एक फाइलर थियो। हामी भित्र गएर हेर्यौं - सबै कुरा व्यवस्थित छ, प्रतिकृतिहरू ठाउँमा छन्, त्यहाँ कुनै प्रतिकृति ढिलाइ छैन। त्यहाँ लगहरूमा कुनै त्रुटिहरू छैनन्, सबै कुरा क्रममा छ।

उत्पादन टोली भन्छ कि त्यहाँ केहि डेटा हुनुपर्छ, तर हामी यसलाई एक स्रोतबाट देख्छौं, तर हामी डाटाबेसमा देख्दैनौं। र हामीले उनीहरूलाई के भयो भनेर बुझ्न आवश्यक छ।

यो स्पष्ट छ कि pg_rewind तिनीहरूलाई छुटेको छ। हामीले तुरुन्तै यो बुझ्यौं, तर के भइरहेको थियो हेर्न गयौं।

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

हाम्रो पुरानो मास्टर रिबुट भयो। र Patroni autorun मा दर्ता भएको थियो। Patroni सुरु गरेको छ। त्यसपछि उनले पोस्टग्रेस सुरु गरे। थप स्पष्ट रूपमा, Postgres सुरु गर्नु अघि र यसलाई प्रतिकृति बनाउनु अघि, Patroni ले pg_rewind प्रक्रिया सुरु गर्यो। तदनुसार, उसले लेनदेन लगहरूको केही अंश मेट्यो, नयाँ डाउनलोड गर्यो र जडान भयो। यहाँ Patroni चलाखीपूर्वक काम गरे, त्यो हो, अपेक्षा गरे जस्तै। क्लस्टर पुनर्स्थापित गरिएको छ। हामीसँग 3 नोडहरू थिए, फाइलर 3 नोडहरू पछि - सबै कुरा राम्रो छ।

हामीले केही डाटा गुमायौं। र हामीले कति गुमायौं भनेर बुझ्नुपर्छ। हामी पल पल खोजिरहेका छौं जब हामी एक रिवाइन्ड थियो। हामी यसलाई त्यस्ता जर्नल प्रविष्टिहरूमा फेला पार्न सक्छौं। रिवाइन्ड सुरु भयो, त्यहाँ केहि गरे र समाप्त भयो।

हामीले लेनदेन लगमा स्थिति फेला पार्न आवश्यक छ जहाँ पुरानो मास्टरले छोडेको थियो। यस अवस्थामा, यो चिन्ह हो। र हामीलाई दोस्रो चिन्ह चाहिन्छ, त्यो दूरी जुन पुरानो मास्टर नयाँ भन्दा फरक छ।

हामी सामान्य pg_wal_lsn_diff लिन्छौं र यी दुई अंकहरू तुलना गर्छौं। र यस अवस्थामा, हामीले 17 मेगाबाइटहरू पाउँछौं। धेरै वा थोरै, सबैले आफ्नै लागि निर्णय गर्छन्। किनभने कसैको लागि 17 मेगाबाइट धेरै होइन, कसैको लागि यो धेरै र अस्वीकार्य छ। यहाँ, प्रत्येक व्यक्तिले आफ्नो लागि व्यवसायको आवश्यकता अनुसार निर्धारण गर्दछ।

तर हामीले आफैलाई के पत्ता लगायौं?

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

र त्यस पछि मात्र हामीले निर्णय गर्नुपर्छ कि हामी यो डाटा खारेज गर्न सक्छौं वा हामी यसलाई पुनर्स्थापित गर्न सक्छौं, यो नोडलाई हाम्रो क्लस्टरमा प्रतिकृतिको रूपमा जडान गर्नुहोस्।

थप रूपमा, त्यहाँ "maximum_lag_on_failover" प्यारामिटर छ। पूर्वनिर्धारित रूपमा, यदि मेरो मेमोरीले मलाई सेवा गर्छ भने, यो प्यारामिटरको मान 1 मेगाबाइट छ।

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

तर त्यहाँ एउटा समस्या छ कि Patroni क्लस्टर र DCS मा प्रतिकृति ढिलाइ एक निश्चित अन्तरालमा अद्यावधिक हुन्छ। मलाई लाग्छ कि 30 सेकेन्ड पूर्वनिर्धारित ttl मान हो।

तदनुसार, त्यहाँ DCS मा प्रतिकृतिहरूका लागि एक प्रतिकृति ढिलाइ भएको अवस्था हुन सक्छ, तर वास्तवमा त्यहाँ पूर्ण रूपमा फरक ढिलाइ हुन सक्छ वा त्यहाँ कुनै पनि ढिलाइ नहुन सक्छ, अर्थात् यो कुरा वास्तविक समय होइन। र यसले सधैं वास्तविक चित्रलाई प्रतिबिम्बित गर्दैन। र यसमा फैंसी तर्क गर्न लायक छैन।

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

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

र अधिकतम_lag_on_failover सेट गरिएको छ र फाइलर आएको छ भने लगहरू यसरी देखिन्छन्, र तपाईंले नयाँ मास्टर चयन गर्न आवश्यक छ। प्रतिकृतिले आफूलाई चुनावमा भाग लिन असक्षम ठानेको छ। र उनले नेताको दौडमा भाग लिन अस्वीकार गरे। र उनी नयाँ मास्टर चयन हुनको लागि पर्खिरहेकी छिन्, ताकि उनी त्यसमा जडान गर्न सकून्। यो डेटा हानि विरुद्ध एक अतिरिक्त उपाय हो।

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

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

एकै समयमा, हामीलाई पहिले नै थाहा थियो कि हामीसँग डिस्कहरूमा समस्याहरू छन्, अर्थात्, हामीले कहाँ खन्ने र के खोज्ने भनेर निगरानीबाट थाहा पाएका थियौं।

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

हामीले प्रणाली dmesg (कर्नेल लग) मा हेर्यौं। र हामीले देख्यौं कि हामीसँग एउटा डिस्कमा समस्या छ। डिस्क सबसिस्टम सफ्टवेयर रेड थियो। हामीले /proc/mdstat हेर्यौं र हामीले एउटा ड्राइभ हराइरहेको देख्यौं। त्यो हो, त्यहाँ 8 डिस्क को एक छापा छ, हामी एक हराइरहेको छ। यदि तपाइँ स्लाइडमा ध्यानपूर्वक हेर्नुभयो भने, त्यसपछि आउटपुटमा तपाईले देख्न सक्नुहुन्छ कि हामीसँग त्यहाँ sde छैन। हामी मा, सशर्त बोल्दै, डिस्क छोडिएको छ। यसले डिस्क समस्याहरू ट्रिगर गर्यो, र पोस्टग्रेस क्लस्टरसँग काम गर्दा अनुप्रयोगहरूले पनि समस्याहरू अनुभव गरे।

र यस अवस्थामा, Patroni ले हामीलाई कुनै पनि हिसाबले मद्दत गर्दैन, किनभने Patroni सँग सर्भरको अवस्था, डिस्कको अवस्था निगरानी गर्ने कार्य छैन। र हामीले त्यस्ता अवस्थाहरूलाई बाह्य अनुगमनद्वारा निगरानी गर्नुपर्छ। हामीले चाँडै बाह्य निगरानीमा डिस्क निगरानी थप्यौं।

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

मेरो विचारमा, यो एउटा अनौठो समस्या हो जुन मैले धेरै लामो समयको लागि अनुसन्धान गरेको छु, मैले धेरै लगहरू पढेको छु, पुन: छानेको छु र यसलाई क्लस्टर सिम्युलेटर भनिन्छ।

समस्या यो थियो कि पुरानो मास्टर एक सामान्य प्रतिकृति बन्न सकेन, अर्थात् Patroni ले सुरु गरे, Patroni ले देखायो कि यो नोड प्रतिकृति रूपमा उपस्थित थियो, तर एकै समयमा यो एक सामान्य प्रतिकृति थिएन। अब तपाइँ किन देख्नुहुनेछ। त्यो समस्याको विश्लेषणबाट मैले यो कुरा राखेको छु।

र यो सबै कसरी सुरु भयो? यो सुरु भयो, अघिल्लो समस्या जस्तै, डिस्क ब्रेक संग। हामीसँग एक सेकेन्ड, दुईको लागि प्रतिबद्धता थियो।

त्यहाँ जडानहरूमा ब्रेकहरू थिए, अर्थात्, ग्राहकहरू च्यातिएका थिए।

विभिन्न गम्भिरताका अवरोधहरू थिए।

र, तदनुसार, डिस्क उपप्रणाली धेरै उत्तरदायी छैन।

र मेरो लागि सबैभन्दा रहस्यमय कुरा भनेको तत्काल बन्द अनुरोध आएको हो। Postgres को तीन शटडाउन मोडहरू छन्:

• यो राम्रो हुन्छ जब हामी सबै क्लाइन्टहरू आफ्नै रूपमा विच्छेद हुनको लागि पर्खन्छौं।
• त्यहाँ छिटो छ जब हामी ग्राहकहरूलाई विच्छेद गर्न बाध्य पार्छौं किनभने हामी बन्द गर्न जाँदैछौं।
• र तत्काल। यस अवस्थामा, तुरुन्तै ग्राहकहरूलाई बन्द गर्न पनि बताउँदैन, यो केवल चेतावनी बिना बन्द हुन्छ। र सबै क्लाइन्टहरूलाई, अपरेटिङ सिस्टमले पहिले नै RST सन्देश पठाउँछ (एक TCP सन्देश जुन जडान अवरुद्ध भएको छ र क्लाइन्टसँग समात्न अरू केही छैन)।

यो संकेत कसले पठायो? पोस्टग्रेस पृष्ठभूमि प्रक्रियाहरूले एकअर्कालाई त्यस्ता संकेतहरू पठाउँदैनन्, अर्थात् यो किल-९ हो। तिनीहरूले त्यस्ता चीजहरू एकअर्कालाई पठाउँदैनन्, तिनीहरू केवल त्यस्ता चीजहरूमा प्रतिक्रिया दिन्छन्, अर्थात् यो पोस्टग्रेसको आपतकालीन पुन: सुरु हो। कसले पठायो, थाहा छैन।

मैले "अन्तिम" आदेशमा हेरेँ र मैले एक व्यक्तिलाई देखेँ जसले हामीसँग यो सर्भरमा लग इन गरेको थियो, तर म प्रश्न सोध्न धेरै शर्मिला थिएँ। सायद मारेको थियो-९। म लगहरूमा मार -9 देख्नेछु, किनभने Postgres भन्छन् कि मार -9 लियो, तर मैले लगहरूमा देखेको छैन।

अगाडि हेर्दै, मैले देखें कि Patroni धेरै लामो समय को लागी लग मा लेखेन - 54 सेकेन्ड। र यदि हामीले दुई टाइमस्ट्याम्पहरू तुलना गर्छौं भने, त्यहाँ लगभग 54 सेकेन्डको लागि कुनै सन्देशहरू थिएनन्।

र यस समयमा त्यहाँ एक स्वत: फाइल थियो। Patroni ले यहाँ फेरि राम्रो काम गर्नुभयो। हाम्रो पुरानो मालिक उपलब्ध थिएन, उहाँलाई केहि भयो। र नयाँ गुरुको चुनाव सुरु भयो। यहाँ सबै कुरा राम्रोसँग काम भयो। हाम्रो pgsql01 नयाँ नेता भएको छ।

हामीसँग एउटा प्रतिकृति छ जुन मास्टर भएको छ। र त्यहाँ दोस्रो प्रतिक्रिया छ। र दोस्रो प्रतिकृतिमा समस्याहरू थिए। उनले पुन: कन्फिगर गर्ने प्रयास गरे। मैले बुझे अनुसार, उनले recovery.conf परिवर्तन गर्ने, Postgres पुन: सुरु गर्ने र नयाँ मास्टरमा जडान गर्ने प्रयास गरिन्। उनी हरेक 10 सेकेन्डमा सन्देशहरू लेख्छिन् जुन उनले प्रयास गरिरहेकी छिन्, तर उनी सफल छैनन्।

र यी प्रयासहरूको समयमा, पुरानो मास्टरमा तत्काल-शटडाउन संकेत आउँछ। मास्टर पुन: सुरु हुन्छ। र रिकभरी पनि रोक्छ किनभने पुरानो मास्टर रिबुटमा जान्छ। अर्थात्, प्रतिकृति यसमा जडान हुन सक्दैन, किनभने यो बन्द मोडमा छ।

केहि बिन्दुमा, यसले काम गर्यो, तर प्रतिकृति सुरु भएन।

मेरो मात्र अनुमान छ कि recovery.conf मा पुरानो मास्टर ठेगाना थियो। र जब नयाँ मास्टर देखा पर्‍यो, दोस्रो प्रतिकृतिले अझै पुरानो मास्टरसँग जडान गर्न खोज्यो।

जब Patroni दोस्रो प्रतिकृतिमा सुरु भयो, नोड सुरु भयो तर नक्कल गर्न सकेन। र एक प्रतिकृति ढिलाइ बनाइयो, जुन यो जस्तो देखिन्थ्यो। त्यो हो, सबै तीन नोडहरू ठाउँमा थिए, तर दोस्रो नोड पछाडि पर्यो।

एकै समयमा, यदि तपाईंले लेखिएका लगहरू हेर्नुभयो भने, तपाईंले देख्न सक्नुहुन्छ कि लेनदेन लगहरू फरक भएकाले प्रतिकृति सुरु हुन सकेन। र ती लेनदेन लगहरू जुन मास्टरले प्रस्ताव गर्दछ, जुन recovery.conf मा निर्दिष्ट गरिएको छ, हाम्रो हालको नोडमा फिट हुँदैन।

र यहाँ मैले गल्ती गरें। हामीले गलत मास्टरसँग जोडिएको मेरो परिकल्पना परीक्षण गर्न recovery.conf मा के छ भनेर मैले आउनुपर्‍यो। तर त्यसबेला म यससँग व्यवहार गरिरहेको थिएँ र यो मलाई लागेन, वा मैले देखे कि प्रतिकृति पछाडि परेको थियो र पुन: भर्नुपर्ने थियो, त्यो हो, मैले कुनै न कुनै रूपमा लापरवाह काम गरें। यो मेरो संयुक्त थियो।

30 मिनेट पछि, प्रशासक पहिले नै आयो, अर्थात् मैले प्रतिकृतिमा Patroni पुन: सुरु गरें। मैले पहिले नै यसको अन्त्य गरिसकेको छु, मैले सोचे कि यो पुन: भर्नुपर्छ। र मैले सोचें - म Patroni पुन: सुरु गर्छु, सायद केहि राम्रो बाहिर जान्छ। रिकभरी सुरु भयो। र आधार पनि खोलियो, यो जडान स्वीकार गर्न तयार थियो।

प्रतिकृया सुरु भएको छ। तर एक मिनेट पछि उनी लेनदेन लगहरू उनको लागि उपयुक्त छैनन् भन्ने त्रुटिको साथ झरिन्।

मैले फेरि पुन: सुरु गर्ने सोचें। मैले Patroni पुन: सुरु गरें, र मैले Postgres पुन: सुरु गरेन, तर Patroni पुन: सुरु गरें कि यसले जादुई रूपमा डाटाबेस सुरु गर्नेछ।

प्रतिकृति फेरि सुरु भयो, तर लेनदेन लगमा अंकहरू फरक थिए, तिनीहरू अघिल्लो सुरु प्रयास जस्तै थिएनन्। पुन: प्रतिकृति रोकियो। र सन्देश पहिले नै अलि फरक थियो। र यो मेरो लागि धेरै जानकारीपूर्ण थिएन।

र त्यसपछि यो मलाई उत्पन्न हुन्छ - यदि मैले Postgres पुन: सुरु गरें भने, यस समयमा मैले लेनदेन लगमा बिन्दुलाई अलि अगाडि सार्नको लागि हालको मास्टरमा चेकपोइन्ट बनाउँछु ताकि रिकभरी अर्को क्षणबाट सुरु हुन्छ? साथै, हामीसँग अझै पनि WAL को स्टक थियो।

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

मेरो लागि यस्तो समस्या अझ रहस्यमय मध्ये एक हो, जसमा म अझै पनि त्यहाँ के भयो भनेर पक्कै पक्कै छु।

यहाँ के प्रभावहरू छन्? Patroni ले उद्देश्य अनुसार र कुनै त्रुटि बिना काम गर्न सक्छ। तर एकै समयमा, यो 100% ग्यारेन्टी होइन कि हामीसँग सबै कुरा ठीक छ। प्रतिकृति सुरु हुन सक्छ, तर यो अर्ध-कार्यरत अवस्थामा हुन सक्छ, र अनुप्रयोगले यस्तो प्रतिकृतिसँग काम गर्न सक्दैन, किनभने त्यहाँ पुरानो डाटा हुनेछ।

र फाइलर पछि, तपाईंले सधैं जाँच गर्न आवश्यक छ कि सबै कुरा क्लस्टरको साथ क्रमबद्ध छ, त्यो हो, त्यहाँ प्रतिकृतिहरूको आवश्यक संख्या छ, त्यहाँ कुनै प्रतिकृति ढिलाइ छैन।

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

जब तपाइँ Patroni प्रयोग गर्नुहुन्छ, तपाइँसँग निगरानी हुनुपर्छ। तपाईलाई सधैं थाहा हुनुपर्छ जब एक अटोफाइलओभर भयो, किनकि यदि तपाईलाई थाहा छैन कि तपाईसँग अटोफाइलओभर थियो, तपाईसँग क्लस्टरमा कुनै नियन्त्रण छैन। र त्यो नराम्रो छ।

प्रत्येक फाइलर पछि, हामीले सधैं म्यानुअल रूपमा क्लस्टर जाँच गर्नुपर्छ। हामीले सुनिश्चित गर्न आवश्यक छ कि हामीसँग सँधै प्रतिकृतिहरूको अप-टु-डेट संख्या छ, त्यहाँ कुनै प्रतिकृति ढिलाइ छैन, स्ट्रिमिङ प्रतिकृतिसँग सम्बन्धित लगहरूमा कुनै त्रुटिहरू छैनन्, Patroni सँग, DCS प्रणालीसँग।

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

र Patroni चाँदीको गोली होइन। हामीले अझै पनि पोष्टग्रेसले कसरी काम गर्छ, कसरी प्रतिकृतिले काम गर्छ र Patroni पोष्टग्रेससँग कसरी काम गर्छ, र नोडहरू बीचको सञ्चार कसरी प्रदान गरिन्छ भन्ने कुरा बुझ्न आवश्यक छ। यो आफ्नो हात संग समस्या समाधान गर्न सक्षम हुन आवश्यक छ।

म कसरी निदानको मुद्दामा पुग्न सक्छु? यस्तो भयो कि हामीले विभिन्न ग्राहकहरूसँग काम गर्छौं र कसैसँग ELK स्ट्याक छैन, र हामीले 6 कन्सोल र 2 ट्याबहरू खोलेर लगहरू क्रमबद्ध गर्नुपर्छ। एउटा ट्याबमा, यी प्रत्येक नोडका लागि Patroni लगहरू हुन्, अर्को ट्याबमा, यी Consul लगहरू, वा Postgres आवश्यक भएमा। यो निदान गर्न धेरै गाह्रो छ।

मैले कस्ता उपाय अपनाएको छु ? पहिलो, म सधैं फाइलर आइपुगेको हेर्छु। र मेरो लागि यो एक वाटरशेड हो। फाइलर अघि, फाइलरको समयमा र फाइलर पछि के भयो म हेर्छु। फाइलओभरमा दुई अंकहरू छन्: यो सुरु र अन्त्य समय हो।

अर्को, म फाइलर अघि घटनाहरूका लागि लगहरूमा हेर्छु, जुन फाइलर अघि थियो, अर्थात् म फाइलर किन भयो भन्ने कारणहरू खोज्छु।

र यसले के भयो र भविष्यमा के गर्न सकिन्छ भनेर बुझ्नको चित्र दिन्छ ताकि त्यस्ता परिस्थितिहरू नहोस् (र परिणामको रूपमा, त्यहाँ कुनै फाइलर छैन)।

र हामी सामान्यतया कहाँ हेर्छौं? म हेर्छु:

• पहिले, Patroni लगहरूमा।
• अर्को, म पोस्टग्रेस लगहरू, वा DCS लगहरू हेर्छु, Patroni लगहरूमा के फेला पर्यो भन्ने आधारमा।
• र प्रणाली लगहरूले कहिलेकाहीं फाइलरको कारण के हो भनेर बुझाउँछ।

मलाई Patroni कस्तो लाग्छ? पाटोनीसँग मेरो धेरै राम्रो सम्बन्ध छ। मेरो विचारमा, यो आजको सबैभन्दा राम्रो हो। मलाई अन्य धेरै उत्पादनहरू थाहा छ। यी हुन् Stolon, Repmgr, Pg_auto_failover, PAF। 4 उपकरणहरू। मैले ती सबै प्रयास गरें। Patroni मेरो मनपर्ने हो।

यदि तिनीहरूले मलाई सोध्छन्: "के म Patroni सिफारिस गर्छु?"। म हो भन्छु, किनकि मलाई Patroni मन पर्छ। र मलाई लाग्छ कि मैले यसलाई कसरी पकाउने भनेर सिकें।

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

त्यहाँ मानिसहरूको खुट्टामा गोली हानेको बारेमा केही रोचक कथाहरू छन्। धेरै जानकारीमूलक। तपाईंले पढ्नुभयो र बुझ्नुभयो कि यो गर्न आवश्यक छैन। मैले आफैंलाई टिकाएँ।

र म यस परियोजनाको विकासको लागि Zalando लाई ठूलो धन्यवाद भन्न चाहन्छु, अर्थात् अलेक्जेंडर कुकुशकिन र एलेक्सी क्ल्युकिनलाई। Aleksey Klyukin सह-लेखकहरू मध्ये एक हो, उनी अब Zalando मा काम गर्दैनन्, तर यी दुई व्यक्ति हुन् जसले यस उत्पादनसँग काम गर्न थाले।

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

यति नै। यदि तपाइँसँग प्रश्नहरू छन् भने, सोध्नुहोस्।

तपाईंका प्रश्नहरू

रिपोर्ट को लागी धन्यवाद! यदि फाइलर पछि तपाइँ अझै पनि त्यहाँ धेरै ध्यानपूर्वक हेर्नु आवश्यक छ भने, त्यसोभए हामीलाई स्वचालित फाइलर किन चाहिन्छ?

किनभने यो नयाँ कुरा हो। हामी उनको साथमा एक वर्ष मात्र भएको छ। सुरक्षित हुनु राम्रो। हामी भित्र आउन चाहन्छौं र हेर्न चाहन्छौं कि सबै कुरा वास्तवमै जसरी काम गर्नुपर्दछ। यो वयस्क अविश्वासको स्तर हो - यो डबल-जाँच र हेर्न राम्रो छ।

उदाहरणको लागि, हामी बिहान गएर हेर्यौं, हैन?

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

धन्यवाद!

महान कथा को लागी धेरै धन्यवाद! यदि हामीले DCS क्लस्टरलाई Postgres क्लस्टरबाट कतै टाढा सारियो भने, यो क्लस्टरलाई पनि आवधिक रूपमा सेवा गर्न आवश्यक छ? DCS क्लस्टरका केही टुक्राहरू बन्द गर्न आवश्यक पर्ने उत्तम अभ्यासहरू के हुन्, तिनीहरूसँग केही गर्नुपर्छ, आदि? यो सम्पूर्ण संरचना कसरी जीवित रहन्छ? अनि तपाईं यी कुराहरू कसरी गर्नुहुन्छ?

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

त्यो हो, के मैले होस्टहरूसँग केहि गर्नु अघि Patroni असक्षम गर्न, फाइलर असक्षम गर्न, सबै असक्षम गर्न आवश्यक छ भनेर सही रूपमा बुझें?

यो DCS क्लस्टरमा हामीसँग कति नोडहरू छन् भन्नेमा निर्भर गर्दछ। यदि त्यहाँ धेरै नोडहरू छन् र यदि हामीले नोडहरू (प्रतिकृति) मध्ये एउटा मात्र असक्षम गर्छौं भने, क्लस्टरले कोरम कायम राख्छ। र Patroni कार्यरत रहन्छ। र केहि पनि ट्रिगर गरिएको छैन। यदि हामीसँग केहि जटिल अपरेसनहरू छन् जसले थप नोडहरूलाई असर गर्छ, जसको अनुपस्थितिले कोरमलाई बर्बाद गर्न सक्छ, तब - हो, Patroni लाई पजमा राख्नु अर्थपूर्ण हुन सक्छ। योसँग सम्बन्धित आदेश छ - patronictl pause, patronictl resume। हामी केवल पज गर्छौं र अटोफिलरले त्यस समयमा काम गर्दैन। हामी DCS क्लस्टरमा मर्मतसम्भार गर्छौं, त्यसपछि हामी पज बन्द गर्छौं र बाँच्न जारी राख्छौं।

सर्प!

तपाईको रिपोर्टको लागि धेरै धेरै धन्यवाद! उत्पादन टोली डेटा हराएको बारेमा कस्तो महसुस गर्छ?

उत्पादन टोलीहरूले वास्ता गर्दैनन्, र टोली नेतृत्वहरू चिन्तित छन्।

त्यहाँ के ग्यारेन्टीहरू छन्?

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

एलेक्सी, महान रिपोर्ट को लागी धन्यवाद! शून्य स्तर सुरक्षा को लागी Patroni प्रयोग संग कुनै अनुभव? त्यो हो, सिंक्रोनस स्ट्यान्डबाइ संग संयोजन मा? यो पहिलो प्रश्न हो। र दोस्रो प्रश्न। तपाईंले विभिन्न समाधानहरू प्रयोग गर्नुभएको छ। हामीले Repmgr प्रयोग गर्यौं, तर autofiler बिना, र अब हामी autofiler समावेश गर्ने योजनामा ​​छौं। र हामी Patroni वैकल्पिक समाधान मान्छौं। तपाईं Repmgr को तुलनामा फाइदाहरूको रूपमा के भन्न सक्नुहुन्छ?

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

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

Repmgr जाँच गर्दछ कि Postgres नोडहरू जीवित छन्। Repmgr प्रक्रियाहरूले एक अर्काको अस्तित्वको लागि जाँच गर्दछ, यो धेरै कुशल दृष्टिकोण होइन। त्यहाँ सञ्जाल अलगावका जटिल अवस्थाहरू हुन सक्छन् जसमा ठूलो Repmgr क्लस्टर धेरै सानाहरूमा विभाजित हुन सक्छ र काम जारी राख्न सक्छ। मैले लामो समयदेखि Repmgr लाई पछ्याएको छैन, सायद यो फिक्स गरिएको थियो ... वा हुन सक्छ। तर DCS मा क्लस्टरको अवस्थाको बारेमा जानकारी हटाउनु, जस्तै Stolon, Patroni ले गर्छ, सबैभन्दा व्यवहार्य विकल्प हो।

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

मैले यो ठूलो स्वरमा भनेको होइन, तर DCS क्लस्टर पनि फेलओभर हुनुपर्छ, अर्थात् यो नोडहरूको बिजोर संख्या हो, कोरम पूरा गर्नको लागि। के हुन्छ यदि DCS क्लस्टर अनुपलब्ध भयो, वा कोरम पूरा गर्न सकिँदैन, अर्थात् केहि प्रकारको नेटवर्क विभाजन वा नोड विफलता? यस अवस्थामा, Patroni क्लस्टर केवल पढ्ने मोडमा जान्छ। Patroni क्लस्टरले क्लस्टरको अवस्था र के गर्ने भनेर निर्धारण गर्न सक्दैन। यसले DCS लाई सम्पर्क गर्न र नयाँ क्लस्टर अवस्थालाई त्यहाँ भण्डारण गर्न सक्दैन, त्यसैले सम्पूर्ण क्लस्टर मात्र पढ्नमा जान्छ। र या त अपरेटरबाट म्यानुअल हस्तक्षेप वा DCS पुन: प्राप्तिको लागि पर्खन्छ।

सामान्य रूपमा भन्नुपर्दा, DCS हाम्रो लागि आधार जत्तिकै महत्त्वपूर्ण सेवा हुन्छ?

हो हो। धेरै आधुनिक कम्पनीहरूमा, सेवा खोज पूर्वाधारको अभिन्न अंग हो। पूर्वाधारमा डाटाबेस हुनुअघि नै यो कार्यान्वयन भइरहेको छ । तुलनात्मक रूपमा भन्नुपर्दा, पूर्वाधार सुरु गरिएको थियो, DC मा तैनात गरिएको थियो, र हामीसँग तुरुन्तै सेवा खोज छ। यदि यो कन्सुलर हो भने, त्यसमा DNS निर्माण गर्न सकिन्छ। यदि यो Etcd हो भने, त्यहाँ Kubernetes क्लस्टरको एक भाग हुन सक्छ, जसमा अरू सबै तैनाथ गरिनेछ। मलाई लाग्छ कि सेवा खोज पहिले नै आधुनिक पूर्वाधारहरूको अभिन्न अंग हो। र तिनीहरू डाटाबेसको बारेमा भन्दा धेरै पहिले यसको बारेमा सोच्छन्।

धन्यवाद!

स्रोत: www.habr.com