Patroni विफलता की कहानियां या अपने PostgreSQL क्लस्टर को कैसे क्रैश करें। एलेक्सी लेसोव्स्की

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

मैं आपको अपने बारे में थोड़ा बताऊंगा। मैंने एक सिस्टम प्रशासक के रूप में शुरुआत की। वेब विकास में काम किया। मैं 2014 से डेटा एग्रेट में काम कर रहा हूं। कंपनी पोस्टग्रेज के क्षेत्र में परामर्श देने में लगी हुई है। और हम बिल्कुल Postgres की सेवा करते हैं, और हम हर दिन Postgres के साथ काम करते हैं, इसलिए हमारे पास ऑपरेशन से संबंधित अलग-अलग विशेषज्ञता है।

और 2018 के अंत में, हमने धीरे-धीरे पैट्रोनी का उपयोग करना शुरू किया। और कुछ अनुभव जमा हो गया है। हमने किसी तरह इसका निदान किया, इसे ट्यून किया, अपनी सर्वोत्तम प्रथाओं पर आए। और इस रिपोर्ट में मैं उनके बारे में बात करेंगे.

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

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

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

और अपनी रिपोर्ट शुरू करने से पहले एक छोटा सा अस्वीकरण।

ये सभी समस्याएं जो हमें मिलीं, वे ऑपरेशन के पहले 6-7-8 महीनों में हमारे पास थीं। समय के साथ, हम अपनी आंतरिक सर्वोत्तम प्रथाओं पर आ गए। और हमारी परेशानी दूर हो गई। इसलिए, रिपोर्ट की घोषणा लगभग छह महीने पहले की गई थी, जब यह सब मेरे दिमाग में ताज़ा था और मुझे यह सब पूरी तरह से याद था।

रिपोर्ट तैयार करने के दौरान, मैंने पहले ही पुराने पोस्टमॉर्टम किए, लॉग देखे। और कुछ विवरणों को भुलाया जा सकता है, या कुछ विवरणों की समस्याओं के विश्लेषण के दौरान पूरी तरह से जांच नहीं की जा सकती है, इसलिए कुछ बिंदुओं पर ऐसा लग सकता है कि समस्याओं पर पूरी तरह से विचार नहीं किया गया है, या जानकारी की कमी है। और इसलिए मैं आपसे इस पल के लिए मुझे क्षमा करने के लिए कहता हूं।

पैट्रोनी क्या है?

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

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

लेकिन जब हम पैट्रोनी का उपयोग करना शुरू करते हैं, तो हमारा सिस्टम थोड़ा और जटिल हो जाता है। यदि पहले हमारे पास Postgres था, तो Patroni का उपयोग करते समय हमें Patroni ही मिलता है, हमें DCS मिलता है जहाँ State Store किया जाता है। और यह सब किसी तरह काम करना है। तो क्या गलत हो सकता है?

टूट सकता है:

• पोस्टग्रेज टूट सकता है। यह मास्टर या प्रतिकृति हो सकता है, उनमें से एक विफल हो सकता है।
• पेट्रोनी ही टूट सकती है।
• डीसीएस जहां राज्य संग्रहीत है, टूट सकता है।
• और नेटवर्क टूट सकता है।

इन सभी बिंदुओं पर मैं रिपोर्ट में विचार करूंगा।

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

और पहला मामला सबसे आसान है। यह वह स्थिति है जब हमने एक डेटाबेस क्लस्टर लिया और अपने DCS स्टोरेज को उसी क्लस्टर पर तैनात किया। यह सबसे आम गलती है। यह आर्किटेक्चर के निर्माण में एक गलती है, यानी विभिन्न घटकों को एक ही स्थान पर जोड़ना।

तो, एक फाइलर था, जो हुआ उससे निपटने के लिए चलते हैं।

और यहां हम रुचि रखते हैं कि फाइलर कब हुआ। यही है, हम इस समय में रुचि रखते हैं जब क्लस्टर राज्य बदल गया।

लेकिन दाखिल करने वाला हमेशा तात्कालिक नहीं होता है, यानी इसमें समय की कोई इकाई नहीं लगती है, इसमें देरी हो सकती है। यह लंबे समय तक चलने वाला हो सकता है।

इसलिए, इसका प्रारंभ समय और अंत समय होता है, यानी यह एक सतत घटना है। और हम सभी घटनाओं को तीन अंतरालों में विभाजित करते हैं: हमारे पास फाइलर से पहले, फाइलर के दौरान और फाइलर के बाद का समय होता है। अर्थात्, हम इस समयरेखा में सभी घटनाओं पर विचार करते हैं।

और पहली बात, जब फाइलर होता है, तो हम देखते हैं कि क्या हुआ, फाइलर के कारण क्या हुआ।

यदि हम लॉग को देखें, तो वे क्लासिक पैट्रोनी लॉग होंगे। उनमें वह हमें बताता है कि सर्वर मास्टर बन गया है, और मास्टर की भूमिका इस नोड में चली गई है। यहाँ इसे हाइलाइट किया गया है।

इसके बाद, हमें यह समझने की आवश्यकता है कि फाइलर क्यों हुआ, यानी ऐसी कौन सी घटनाएँ हुईं जिनके कारण मास्टर भूमिका एक नोड से दूसरे नोड में चली गई। और इस मामले में सब कुछ सरल है। स्टोरेज सिस्टम के साथ इंटरैक्ट करने में हमें एक त्रुटि हुई है। उस्ताद को अहसास हुआ कि वह डीसीएस के साथ काम नहीं कर सकते, यानी बातचीत में किसी तरह की दिक्कत आ रही थी। और वह कहता है कि वह अब मास्टर नहीं रह सकता और इस्तीफा दे देता है। यह लाइन "डिमोटेड सेल्फ" बिल्कुल यही कहती है।

यदि हम फाइलर से पहले की घटनाओं को देखते हैं, तो हम वहां वही कारण देख सकते हैं जो विज़ार्ड की निरंतरता के लिए समस्या थी।

अगर हम पैट्रोनी लॉग को देखें, तो हम देखेंगे कि हमारे पास बहुत सारी त्रुटियां हैं, टाइमआउट, यानी पेट्रोनी एजेंट डीसीएस के साथ काम नहीं कर सकता है। इस मामले में, यह कौंसल एजेंट है, जो पोर्ट 8500 पर संचार कर रहा है।

और यहाँ समस्या यह है कि पैट्रोनी और डेटाबेस एक ही होस्ट पर चल रहे हैं। और कॉन्सल सर्वर उसी नोड पर लॉन्च किए गए थे। सर्वर पर लोड बनाकर, हमने कौंसल सर्वर के लिए भी समस्याएँ पैदा कीं। वे ठीक से संवाद नहीं कर पाए।

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

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

और यहाँ समस्या इस तथ्य के कारण उत्पन्न हुई कि कौंसल सर्वर आधार के समान हार्डवेयर पर हैं। तदनुसार, कोई भी लोड: चाहे वह डिस्क या प्रोसेसर पर लोड हो, कॉन्सुल क्लस्टर के साथ बातचीत को भी प्रभावित करता है।

और हमने तय किया कि यह एक साथ नहीं रहना चाहिए, हमने कौंसल के लिए एक अलग क्लस्टर आवंटित किया। और पेट्रोनी पहले से ही एक अलग कौंसल के साथ काम कर रहा था, यानी एक अलग पोस्टग्रेज क्लस्टर, एक अलग कॉन्सल क्लस्टर था। यह एक बुनियादी निर्देश है कि इन सभी चीजों को कैसे ले जाना और रखना है ताकि यह एक साथ न रहे।

एक विकल्प के रूप में, आप पैरामीटर ttl, loop_wait, retry_timeout को घुमा सकते हैं, यानी इन मापदंडों को बढ़ाकर इन अल्पकालिक लोड चोटियों को जीवित रखने का प्रयास करें। लेकिन यह सबसे उपयुक्त विकल्प नहीं है, क्योंकि यह भार लंबे समय तक हो सकता है। और हम बस इन मापदंडों की इन सीमाओं से परे जाएंगे। और वह वास्तव में मदद नहीं कर सकता है।

पहली समस्या, जैसा कि आप समझते हैं, सरल है। हमने DCS को आधार के साथ लिया और रखा, हमें एक समस्या हुई।

दूसरी समस्या पहली जैसी ही है। यह समान है कि हमें फिर से DCS सिस्टम के साथ इंटरऑपरेबिलिटी की समस्या है।

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

बूढ़ा मास्टर एक प्रतिकृति बन जाता है, यहाँ पेट्रोनी काम करता है, जैसा कि उसे होना चाहिए। यह लेन-देन लॉग को रिवाइंड करने के लिए pg_rewind चलाता है और फिर नए मास्टर से जुड़ने के लिए नए मास्टर से जुड़ता है। यहाँ पेट्रोनी काम करता है, जैसा उसे करना चाहिए।

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

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

और उस बिंदु तक स्क्रॉल करने पर जहाँ त्रुटियाँ दिखाई देने लगीं, हम देखते हैं कि हमारे पास एक ऑटो-फाइलओवर है। और चूँकि हमारी त्रुटियाँ DCS के साथ बातचीत से संबंधित थीं और हमारे मामले में हमने कौंसल का उपयोग किया, हम कॉन्सुल लॉग्स को भी देखते हैं कि वहाँ क्या हुआ।

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

और यदि आप अन्य कौंसुल एजेंटों के लॉग को देखते हैं, तो आप यह भी देख सकते हैं कि वहां किसी प्रकार का नेटवर्क क्रैश हो रहा है। और कॉन्सुल क्लस्टर के सभी सदस्य एक दूसरे के अस्तित्व पर संदेह करते हैं। और यही फाइलर के लिए प्रेरणा थी।

यदि आप देखते हैं कि इन त्रुटियों से पहले क्या हुआ था, तो आप देख सकते हैं कि सभी प्रकार की त्रुटियां हैं, उदाहरण के लिए, समय सीमा, RPC गिर गई, अर्थात, कौंसुल क्लस्टर सदस्यों की एक दूसरे के साथ बातचीत में स्पष्ट रूप से किसी प्रकार की समस्या है .

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

विकल्प हैं:

• सबसे सरल विकल्प, जो लिखा गया है, मेरी राय में, यहां तक ​​​​कि प्रलेखन में भी, कॉन्सुल चेक को अक्षम करना है, अर्थात, बस एक खाली सरणी पास करें। और हम कॉन्सुल एजेंट को किसी भी चेक का उपयोग नहीं करने के लिए कहते हैं। इन जांचों के साथ, हम इन नेटवर्क तूफानों को अनदेखा कर सकते हैं और फाइलर शुरू नहीं कर सकते हैं।
• एक और विकल्प है कि आप दो बार जांच करेंraft_multiplier। यह कौंसल सर्वर का ही एक पैरामीटर है। डिफ़ॉल्ट रूप से, यह 5 पर सेट है। स्टेजिंग वातावरण के लिए प्रलेखन द्वारा इस मान की अनुशंसा की जाती है। वास्तव में, यह कौंसल नेटवर्क के सदस्यों के बीच संदेश भेजने की आवृत्ति को प्रभावित करता है। वास्तव में, यह पैरामीटर कौंसल क्लस्टर के सदस्यों के बीच सेवा संचार की गति को प्रभावित करता है। और उत्पादन के लिए पहले से ही इसे कम करने की सिफारिश की जाती है ताकि नोड्स अधिक बार संदेशों का आदान-प्रदान करें।
• एक अन्य विकल्प जो हम लेकर आए हैं वह है ऑपरेटिंग सिस्टम के प्रोसेस शेड्यूलर के लिए अन्य प्रक्रियाओं के बीच कॉन्सल प्रक्रियाओं की प्राथमिकता बढ़ाना। ऐसा "अच्छा" पैरामीटर है, यह केवल उन प्रक्रियाओं की प्राथमिकता निर्धारित करता है जिन्हें शेड्यूलिंग करते समय ओएस अनुसूचक द्वारा ध्यान में रखा जाता है। हमने कांसुल एजेंटों के लिए अच्छा मूल्य भी कम कर दिया है, अर्थात। प्राथमिकता बढ़ा दी ताकि ऑपरेटिंग सिस्टम कॉन्सल प्रक्रियाओं को काम करने और उनके कोड को निष्पादित करने के लिए अधिक समय दे। हमारे मामले में, इसने हमारी समस्या का समाधान किया।
• एक अन्य विकल्प कंसुल का उपयोग नहीं करना है। मेरा एक दोस्त है जो Etcd का बहुत बड़ा समर्थक है। और हम नियमित रूप से उसके साथ बहस करते हैं कि कौन सा बेहतर है Etcd या कौंसल। लेकिन किस मामले में बेहतर है, हम आम तौर पर उससे सहमत होते हैं कि कौंसल के पास एक एजेंट है जो डेटाबेस के साथ प्रत्येक नोड पर चलना चाहिए। यही है, कौंसल क्लस्टर के साथ पैट्रोनी की बातचीत इस एजेंट के माध्यम से होती है। और यह एजेंट अड़चन बन जाता है। अगर एजेंट को कुछ हो जाता है, तो पैट्रोनी अब कौंसल क्लस्टर के साथ काम नहीं कर सकता है। और यही समस्या है। Etcd प्लान में कोई एजेंट नहीं है। पेट्रोनी Etcd सर्वरों की सूची के साथ सीधे काम कर सकता है और पहले से ही उनके साथ संवाद कर सकता है। इस संबंध में, यदि आप अपनी कंपनी में Etcd का उपयोग करते हैं, तो Consul की तुलना में Etcd शायद एक बेहतर विकल्प होगा। लेकिन हम अपने ग्राहकों पर हमेशा सीमित होते हैं कि ग्राहक ने क्या चुना है और क्या उपयोग करता है। और हमारे पास अधिकांश ग्राहकों के लिए कौंसल है।
• और अंतिम बिंदु पैरामीटर मानों को संशोधित करना है। हम इन मापदंडों को इस उम्मीद में बढ़ा सकते हैं कि हमारी अल्पकालिक नेटवर्क समस्याएं कम होंगी और इन मापदंडों की सीमा से बाहर नहीं होंगी। इस तरह हम पैट्रोनी की आक्रामकता को ऑटोफाइल करने के लिए कम कर सकते हैं यदि कुछ नेटवर्क समस्याएँ होती हैं।

मुझे लगता है कि पेट्रोनी का उपयोग करने वाले बहुत से लोग इस आदेश से परिचित हैं।

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

तदनुसार, एक ऑटोफाइल था। और इस ऑटोफाइल के बाद हमारी प्रतिकृति गायब हो गई। हमें यह पता लगाने की जरूरत है कि वह क्यों गायब हुई और उसे वापस लाने, उसे बहाल करने की जरूरत है। और हम फिर से लॉग में जाते हैं और देखते हैं कि हमारे पास ऑटो-फाइलओवर क्यों था।

इस मामले में, दूसरी प्रतिकृति मास्टर बन गई। यहाँ सब ठीक है।

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

इस स्थिति में, हमारे पास लेन-देन लॉग नहीं है और प्रतिकृति प्रारंभ नहीं हो सकती है। तदनुसार, हम पोस्टग्रेज को एक त्रुटि के साथ रोकते हैं। और इसलिए यह क्लस्टर में नहीं है।

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

मैंने टाइमस्टैम्प की तुलना तब की जब ये घटनाएँ हुईं। और वहाँ का अंतर शाब्दिक रूप से 150 मिलीसेकंड है, यानी चेकपॉइंट 369 मिलीसेकंड में पूरा हुआ, वाल सेगमेंट का नाम बदल दिया गया। और सचमुच 517 में, 150 मिलीसेकंड के बाद, पुरानी प्रतिकृति पर रिवाइंड शुरू हुआ। यानी सचमुच 150 मिलीसेकंड हमारे लिए काफी थे ताकि रेप्लिका जुड़ न सके और कमाई न कर सके।

विकल्प क्या हैं?

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

लेकिन यहाँ एक समस्या है, कि जब मास्टर प्रतिकृति के पास जाता है, तो वह स्लॉट्स को हटा देता है और स्लॉट्स के साथ-साथ वाल सेगमेंट को भी हटा देता है। और इस समस्या को दूर करने के लिए, हमने wal_keep_segments पैरामीटर को बढ़ाने का निर्णय लिया। यह 8 खंडों के लिए डिफ़ॉल्ट है। हमने इसे बढ़ाकर 1 कर दिया और देखा कि हमारे पास कितनी खाली जगह है। और हमने wal_keep_segments के लिए 000 गीगाबाइट दान किए। यही है, स्विच करते समय, हमारे पास हमेशा सभी नोड्स पर 16 गीगाबाइट लेनदेन लॉग का रिजर्व होता है।

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

हमारे पास प्रोडक्शन बेस है। पहले से ही प्रगति पर परियोजनाएं हैं।

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

उत्पाद टीम का कहना है कि कुछ डेटा होना चाहिए, लेकिन हम इसे एक स्रोत से देखते हैं, लेकिन हम इसे डेटाबेस में नहीं देखते हैं। और हमें यह समझने की जरूरत है कि उनके साथ क्या हुआ।

यह स्पष्ट है कि pg_rewind ने उन्हें याद किया। हम तुरंत यह समझ गए, लेकिन देखने गए कि क्या हो रहा है।

लॉग में, हम हमेशा यह पता लगा सकते हैं कि फाइलर कब हुआ, कौन मास्टर बन गया, और हम यह निर्धारित कर सकते हैं कि पुराना मास्टर कौन था और वह कब प्रतिकृति बनना चाहता था, यानी हमें लेन-देन लॉग की मात्रा का पता लगाने के लिए इन लॉग की आवश्यकता है खो गया था।

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

हमने कुछ डेटा खो दिया है। और हमें यह समझने की जरूरत है कि हमने कितना खोया है। हम बस उस क्षण की तलाश कर रहे हैं जब हमने रिवाइंड किया था। हम इसे ऐसी जर्नल प्रविष्टियों में पा सकते हैं। रिवाइंड शुरू हुआ, वहीं कुछ किया और खत्म हो गया।

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

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

लेकिन हमने अपने लिए क्या खोजा है?

सबसे पहले, हमें अपने लिए निर्णय लेना चाहिए - क्या सिस्टम रिबूट के बाद हमें हमेशा पैट्रोनी को ऑटोस्टार्ट करने की आवश्यकता होती है? अक्सर ऐसा होता है कि हमें पुराने मालिक के पास जाना पड़ता है, देखें कि वह कितनी दूर चला गया है। शायद लेन-देन लॉग के सेगमेंट का निरीक्षण करें, देखें कि वहां क्या है। और यह समझने के लिए कि क्या हम इस डेटा को खो सकते हैं या इस डेटा को बाहर निकालने के लिए हमें पुराने मास्टर को स्टैंडअलोन मोड में चलाने की आवश्यकता है या नहीं।

और उसके बाद ही हमें यह तय करना होगा कि क्या हम इस डेटा को छोड़ सकते हैं या हम इसे पुनर्स्थापित कर सकते हैं, इस नोड को हमारे क्लस्टर से प्रतिकृति के रूप में जोड़ सकते हैं।

इसके अलावा, एक "अधिकतम_लैग_ऑन_फेलओवर" पैरामीटर है। डिफ़ॉल्ट रूप से, यदि मेरी मेमोरी मेरी सेवा करती है, तो इस पैरामीटर का मान 1 मेगाबाइट है।

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

लेकिन इसमें एक समस्या है कि पैट्रोनी क्लस्टर और DCS में प्रतिकृति लैग एक निश्चित अंतराल पर अपडेट किया जाता है। मुझे लगता है कि 30 सेकंड डिफ़ॉल्ट टीटीएल मान है।

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

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

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

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

यहां हमारे पास एक उत्पाद टीम है जिसने लिखा है कि उनके उत्पाद को पोस्टग्रेज के साथ समस्या हो रही है। उसी समय, मास्टर को स्वयं एक्सेस नहीं किया जा सकता क्योंकि यह SSH के माध्यम से उपलब्ध नहीं है। और ऑटोफाइल भी नहीं होता है।

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

साथ ही, हम पहले से जानते थे कि हमें डिस्क के साथ समस्याएं थीं, यानी, हम निगरानी से पहले से ही जानते थे कि कहां खोदना है और क्या देखना है।

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

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

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

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

मेरी राय में, यह सबसे अजीब समस्याओं में से एक है, जिस पर मैंने बहुत लंबे समय तक शोध किया है, मैंने बहुत सारे लॉग पढ़े, फिर से चुने और इसे क्लस्टर सिम्युलेटर कहा।

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

और यह सब कैसे शुरू हुआ? यह डिस्क ब्रेक के साथ, पिछली समस्या की तरह शुरू हुआ। हमने एक सेकंड, दो के लिए कमिट किया था।

कनेक्शन टूट गए थे, यानी ग्राहक फट गए थे।

अलग-अलग गंभीरता के अवरोध थे।

और, तदनुसार, डिस्क सबसिस्टम बहुत उत्तरदायी नहीं है।

और मेरे लिए सबसे रहस्यमयी चीज तत्काल शटडाउन अनुरोध है जो आ गया है। पोस्टग्रेज के तीन शटडाउन मोड हैं:

• जब हम सभी ग्राहकों के अपने आप डिस्कनेक्ट होने की प्रतीक्षा करते हैं तो यह बहुत अच्छा होता है।
• तेजी से होता है जब हम ग्राहकों को डिस्कनेक्ट करने के लिए मजबूर करते हैं क्योंकि हम शटडाउन करने जा रहे हैं।
• और तत्काल। इस मामले में, तत्काल ग्राहकों को बंद करने के लिए भी नहीं कहता है, यह बिना किसी चेतावनी के बस बंद हो जाता है। और सभी ग्राहकों के लिए, ऑपरेटिंग सिस्टम पहले से ही एक आरएसटी संदेश भेजता है (एक टीसीपी संदेश जो कनेक्शन बाधित है और क्लाइंट के पास पकड़ने के लिए और कुछ नहीं है)।

यह संकेत किसने भेजा? पोस्टग्रेज बैकग्राउंड प्रोसेस एक दूसरे को ऐसे सिग्नल नहीं भेजते हैं, यानी यह किल-9 है। वे एक-दूसरे को ऐसी चीजें नहीं भेजते हैं, वे केवल ऐसी चीजों पर प्रतिक्रिया करते हैं, यानी यह पोस्टग्रेज का आपातकालीन पुनरारंभ है। किसने भेजा है, मुझे नहीं पता।

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

आगे देखते हुए, मैंने देखा कि पेट्रोनी ने लॉग को काफी लंबे समय तक नहीं लिखा - 54 सेकंड। और अगर हम दो टाइमस्टैंप की तुलना करें तो करीब 54 सेकेंड तक कोई मैसेज नहीं आया।

और इसी दौरान ऑटोफाइल हो गया। पेट्रोनी ने यहां फिर से शानदार काम किया है। हमारे पुराने मास्टर अनुपलब्ध थे, उन्हें कुछ हुआ। और एक नए मास्टर का चुनाव शुरू हुआ। यहां सब कुछ ठीक ठाक रहा। हमारा pgsql01 नया लीडर बन गया है।

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

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

किसी बिंदु पर, यह काम किया, लेकिन प्रतिकृति शुरू नहीं हुई।

मेरा एकमात्र अनुमान है कि पुनर्प्राप्ति.कॉन्फ़ में एक पुराना मास्टर पता था। और जब एक नया मास्टर प्रकट हुआ, तब भी दूसरी प्रतिकृति ने पुराने मास्टर से जुड़ने की कोशिश की।

जब पेट्रोनी ने दूसरी प्रतिकृति शुरू की, तो नोड शुरू हो गया लेकिन प्रतिकृति नहीं बना सका। और एक रेप्लिकेशन लैग बन गया, जो कुछ इस तरह दिख रहा था। यानी तीनों नोड अपनी जगह पर थे, लेकिन दूसरा नोड पिछड़ गया।

उसी समय, यदि आप लिखे गए लॉग को देखते हैं, तो आप देख सकते हैं कि प्रतिकृति प्रारंभ नहीं हो सकती क्योंकि लेनदेन लॉग अलग थे। और वे लेन-देन लॉग जो मास्टर ऑफ़र करता है, जो पुनर्प्राप्ति.कॉन्फ़ में निर्दिष्ट हैं, बस हमारे वर्तमान नोड में फिट नहीं होते हैं।

और यहीं मुझसे गलती हो गई। मुझे अपनी परिकल्पना का परीक्षण करने के लिए कि हम गलत मास्टर से जुड़ रहे थे, यह देखने के लिए मुझे आना पड़ा और पुनर्प्राप्ति.conf में क्या था। लेकिन तब मैं बस इससे निपट रहा था और यह मेरे साथ नहीं हुआ, या मैंने देखा कि प्रतिकृति पिछड़ रही थी और उसे फिर से भरना होगा, यानी मैंने किसी तरह लापरवाही से काम किया। यह मेरा जोड़ था।

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

नकल शुरू हो गई है। लेकिन एक मिनट बाद, वह एक त्रुटि के साथ गिर गई कि लेन-देन लॉग उसके लिए उपयुक्त नहीं हैं।

मैंने सोचा कि मैं फिर से शुरू करूँगा। मैंने पैट्रोनी को फिर से शुरू किया, और मैंने पोस्टग्रेज को फिर से शुरू नहीं किया, लेकिन पेट्रोनी को इस उम्मीद में फिर से शुरू किया कि यह डेटाबेस को जादुई रूप से शुरू कर देगा।

प्रतिकृति फिर से शुरू हुई, लेकिन लेन-देन लॉग में निशान अलग थे, वे पिछले प्रारंभ प्रयास के समान नहीं थे। प्रतिकृति फिर से रुक गई। और संदेश पहले से थोड़ा अलग था। और यह मेरे लिए बहुत जानकारीपूर्ण नहीं था।

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

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

मेरे लिए इस तरह की समस्या अधिक रहस्यमयी है, जिसके बारे में मैं अभी भी पहेली बना रहा हूं कि वास्तव में वहां क्या हुआ था।

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

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

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

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

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

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

और पेट्रोनी चांदी की गोली नहीं है। हमें अभी भी यह समझने की जरूरत है कि पोस्टग्रेज कैसे काम करता है, प्रतिकृति कैसे काम करती है और पोस्टग्रेज के साथ पैट्रोनी कैसे काम करती है और नोड्स के बीच संचार कैसे प्रदान किया जाता है। अपने हाथों से समस्याओं को ठीक करने में सक्षम होने के लिए यह आवश्यक है।

मैं निदान के मुद्दे से कैसे संपर्क करूं? ऐसा हुआ कि हम अलग-अलग क्लाइंट्स के साथ काम करते हैं और किसी के पास ELK स्टैक नहीं है, और हमें 6 कंसोल और 2 टैब खोलकर लॉग को सॉर्ट करना होगा। एक टैब में, ये प्रत्येक नोड के लिए पैट्रोनी लॉग हैं, दूसरे टैब में, ये कौंसल लॉग हैं, या यदि आवश्यक हो तो पोस्टग्रेज करते हैं। इसका निदान करना बहुत कठिन है।

मैंने कौन से दृष्टिकोण अपनाए हैं? सबसे पहले, मैं हमेशा देखता हूं कि फाइलर कब आया है। और मेरे लिए यह एक वाटरशेड है। मैं देखता हूं कि फाइलर से पहले, फाइलर के दौरान और फाइलर के बाद क्या हुआ। फाइलओवर के दो चिह्न हैं: यह प्रारंभ और समाप्ति समय है।

अगला, मैं फाइलर से पहले की घटनाओं के लिए लॉग देखता हूं, जो फाइलर से पहले होता है, यानी मैं फाइलर क्यों हुआ इसके कारणों की तलाश करता हूं।

और यह समझने की एक तस्वीर देता है कि क्या हुआ और भविष्य में क्या किया जा सकता है ताकि ऐसी परिस्थितियां उत्पन्न न हों (और नतीजतन, कोई फाइलर नहीं है)।

और हम आमतौर पर कहाँ देखते हैं? मैंने देखता हूं:

• सबसे पहले, पेट्रोनी लॉग्स के लिए।
• अगला, मैं पैट्रोनी लॉग में जो पाया गया था, उसके आधार पर पोस्टग्रेज लॉग या डीसीएस लॉग को देखता हूं।
• और सिस्टम लॉग भी कभी-कभी फाइलर के कारण की समझ देते हैं।

मैं पेट्रोनी के बारे में कैसा महसूस करता हूं? पेट्रोनी के साथ मेरे बहुत अच्छे संबंध हैं। मेरी राय में, यह आज का सबसे अच्छा है। मैं कई अन्य उत्पादों को जानता हूं। ये स्टोलन, रेपमग्र, पीजी_ऑटो_फेलओवर, पीएएफ हैं। 4 उपकरण। मैंने उन सभी को आजमाया। पेट्रोनी मेरी पसंदीदा है।

अगर वे मुझसे पूछते हैं: "क्या मैं पेट्रोनी की सिफारिश करता हूं?"। मैं हां कहूंगी, क्योंकि मुझे पैट्रोनी पसंद है। और मुझे लगता है कि मैंने इसे खाना बनाना सीख लिया है।

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

खुद को पैर में गोली मारने वाले लोगों के बारे में कुछ दिलचस्प कहानियां हैं। बहुत सूचनाप्रद। आप पढ़िए और समझिए कि ऐसा करना जरूरी नहीं है। मैंने खुद को टोका।

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

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

बस इतना ही। यदि आपके कोई प्रश्न हैं, तो पूछें।

सवाल

रिपोर्ट के लिए धन्यवाद! यदि एक फाइलर के बाद भी आपको वहां बहुत ध्यान से देखने की जरूरत है, तो हमें स्वचालित फाइलर की आवश्यकता क्यों है?

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

उदाहरण के लिए, हम सुबह गए और देखा, है ना?

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

शुक्रिया!

बढ़िया कहानी के लिए बहुत-बहुत धन्यवाद! यदि हम DCS क्लस्टर को Postgres क्लस्टर से कहीं दूर ले जाते हैं, तो इस क्लस्टर को भी समय-समय पर सर्विस करने की आवश्यकता होती है? डीसीएस क्लस्टर के कुछ टुकड़ों को बंद करने, उनके साथ कुछ करने आदि के लिए सर्वोत्तम प्रथाएं क्या हैं? यह पूरी संरचना कैसे जीवित रहती है? और आप ये चीज़ें कैसे करते हैं?

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

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

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

большое Спасибо!

आपकी रिपोर्ट के लिए बहुत-बहुत धन्यवाद! उत्पाद टीम डेटा खो जाने के बारे में कैसा महसूस करती है?

उत्पाद टीमों को परवाह नहीं है, और टीम लीड चिंतित हैं।

क्या गारंटी हैं?

गारंटी बहुत कठिन है। अलेक्जेंडर कुकुश्किन की एक रिपोर्ट है "आरपीओ और आरटीओ की गणना कैसे करें", यानी पुनर्प्राप्ति समय और हम कितना डेटा खो सकते हैं। मुझे लगता है कि हमें इन स्लाइड्स को खोजने और उनका अध्ययन करने की आवश्यकता है। जहां तक ​​​​मुझे याद है, इन चीजों की गणना करने के तरीके पर विशिष्ट कदम हैं। हम कितने लेन-देन खो सकते हैं, हम कितना डेटा खो सकते हैं। एक विकल्प के रूप में, हम पैट्रोनी स्तर पर तुल्यकालिक प्रतिकृति का उपयोग कर सकते हैं, लेकिन यह एक दोधारी तलवार है: हमारे पास या तो डेटा विश्वसनीयता है, या हम गति खो देते हैं। तुल्यकालिक प्रतिकृति है, लेकिन यह डेटा हानि के खिलाफ 100% सुरक्षा की गारंटी भी नहीं देता है।

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

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

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

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

एलेक्सी, मेरे पास एक प्रश्न है, शायद एक लमर। पहले उदाहरणों में से एक में, आपने DCS को स्थानीय मशीन से दूरस्थ होस्ट में स्थानांतरित कर दिया। हम समझते हैं कि नेटवर्क एक ऐसी चीज है जिसकी अपनी विशेषताएं हैं, यह अपने आप में रहता है। और क्या होता है अगर किसी कारण से डीसीएस क्लस्टर अनुपलब्ध हो जाता है? मैं कारण नहीं कहूंगा, उनमें से बहुत सारे हो सकते हैं: नेटवर्करों के कुटिल हाथों से लेकर वास्तविक समस्याओं तक।

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

मोटे तौर पर, DCS हमारे लिए उतनी ही महत्वपूर्ण सेवा बन जाती है जितनी कि स्वयं आधार?

हां हां। इतनी सारी आधुनिक कंपनियों में सर्विस डिस्कवरी बुनियादी ढांचे का एक अभिन्न अंग है। इंफ्रास्ट्रक्चर में डेटाबेस होने से पहले भी इसे लागू किया जा रहा है। अपेक्षाकृत बोलते हुए, बुनियादी ढांचा लॉन्च किया गया था, डीसी में तैनात किया गया था, और हमारे पास तुरंत सर्विस डिस्कवरी है। यदि यह कौंसल है, तो उस पर DNS बनाया जा सकता है। यदि यह Etcd है, तो कुबेरनेट्स क्लस्टर का एक हिस्सा हो सकता है, जिसमें बाकी सब कुछ तैनात किया जाएगा। मुझे ऐसा लगता है कि सर्विस डिस्कवरी पहले से ही आधुनिक बुनियादी ढांचे का एक अभिन्न अंग है। और वे इसके बारे में डेटाबेस की तुलना में बहुत पहले सोचते हैं।

शुक्रिया!

स्रोत: www.habr.com