Patroni Failure Stories किंवा तुमचे PostgreSQL क्लस्टर कसे क्रॅश करायचे. अलेक्सी लेसोव्स्की

Patroni चे मुख्य ध्येय PostgreSQL साठी उच्च उपलब्धता प्रदान करणे आहे. पण Patroni हे फक्त एक टेम्प्लेट आहे, रेडीमेड टूल नाही (जे, सर्वसाधारणपणे, डॉक्युमेंटेशनमध्ये सांगितले जाते). पहिल्या दृष्टीक्षेपात, चाचणी प्रयोगशाळेत Patroni सेट केल्यावर, आपण पाहू शकता की ते किती चांगले साधन आहे आणि ते क्लस्टर तोडण्याचे आमचे प्रयत्न किती सहजपणे हाताळते. तथापि, सराव मध्ये, उत्पादन वातावरणात, चाचणी प्रयोगशाळेत सर्वकाही नेहमीच सुंदर आणि सुरेखपणे घडत नाही.

मी तुम्हाला माझ्याबद्दल थोडेसे सांगेन. मी एक सिस्टम प्रशासक म्हणून सुरुवात केली. वेब डेव्हलपमेंटमध्ये काम केले. मी 2014 पासून डेटा एग्रेट येथे काम करत आहे. कंपनी पोस्टग्रेस क्षेत्रात सल्लामसलत करण्यात गुंतलेली आहे. आणि आम्ही पोस्टग्रेसची अचूक सेवा करतो आणि आम्ही दररोज पोस्टग्रेस सोबत काम करतो, त्यामुळे आमच्याकडे ऑपरेशनशी संबंधित भिन्न कौशल्ये आहेत.

आणि 2018 च्या शेवटी, आम्ही हळूहळू Patroni वापरण्यास सुरुवात केली. आणि काही अनुभव जमा झाला आहे. आम्ही कसे तरी त्याचे निदान केले, ते ट्यून केले, आमच्या सर्वोत्तम पद्धतींवर आलो. आणि या अहवालात मी त्यांच्याबद्दल बोलणार आहे.

पोस्टग्रेस व्यतिरिक्त, मला लिनक्स आवडतात. मला त्यात फिरायला आणि एक्सप्लोर करायला आवडते, मला कोर गोळा करायला आवडते. मला आभासीकरण, कंटेनर, डॉकर, कुबर्नेट्स आवडतात. हे सर्व मला आवडले आहे, कारण जुन्या अॅडमिनच्या सवयींवर परिणाम होत आहे. मला मॉनिटरिंगला सामोरे जायला आवडते. आणि मला प्रशासनाशी संबंधित पोस्टग्रेस गोष्टी आवडतात, म्हणजे प्रतिकृती, बॅकअप. आणि माझ्या फावल्या वेळात मी गो मध्ये लिहितो. मी सॉफ्टवेअर अभियंता नाही, मी फक्त गो मध्ये माझ्यासाठी लिहितो. आणि ते मला आनंद देते.

• मला वाटते की तुमच्यापैकी अनेकांना माहित आहे की पोस्टग्रेसमध्ये बॉक्सच्या बाहेर HA (उच्च उपलब्धता) नाही. HA मिळविण्यासाठी, तुम्हाला काहीतरी स्थापित करणे, ते कॉन्फिगर करणे, प्रयत्न करणे आणि ते मिळवणे आवश्यक आहे.
• अनेक साधने आहेत आणि Patroni हे त्यापैकी एक आहे जे HA खूप छान आणि चांगले सोडवते. परंतु हे सर्व एका चाचणी प्रयोगशाळेत टाकून आणि ते चालवून, आपण पाहू शकतो की हे सर्व कार्य करते, आपण काही समस्यांचे पुनरुत्पादन करू शकतो, Patroni त्यांची सेवा कशी करते ते पाहू शकतो. आणि आम्ही पाहू की हे सर्व चांगले कार्य करते.
• पण व्यवहारात आम्हाला वेगवेगळ्या समस्यांचा सामना करावा लागला. आणि मी या समस्यांबद्दल बोलेन.
• मी तुम्हाला सांगेन की आम्ही त्याचे निदान कसे केले, आम्ही काय ट्विक केले - यामुळे आम्हाला मदत झाली की नाही.

• Patroni कसे स्थापित करावे हे मी तुम्हाला सांगणार नाही, कारण तुम्ही इंटरनेटवर गुगल करू शकता, हे सर्व कसे सुरू होते, ते कसे कॉन्फिगर केले आहे हे समजून घेण्यासाठी तुम्ही कॉन्फिगरेशन फाइल्स पाहू शकता. इंटरनेटवर त्याबद्दल माहिती शोधून तुम्ही स्कीम, आर्किटेक्चर समजू शकता.
• मी दुसऱ्याच्या अनुभवाबद्दल बोलणार नाही. मी फक्त आपल्या समोर आलेल्या समस्यांबद्दल बोलेन.
• आणि मी Patroni आणि PostgreSQL च्या बाहेर असलेल्या समस्यांबद्दल बोलणार नाही. जर, उदाहरणार्थ, समतोल साधण्याशी संबंधित समस्या असतील, जेव्हा आमचे क्लस्टर कोसळले असेल, मी त्याबद्दल बोलणार नाही.

आणि आम्ही आमचा अहवाल सुरू करण्यापूर्वी एक छोटा अस्वीकरण.

या सर्व समस्या ज्या आम्हाला आल्या, त्या ऑपरेशनच्या पहिल्या 6-7-8 महिन्यांत आम्हाला आल्या. कालांतराने, आम्ही आमच्या अंतर्गत सर्वोत्तम पद्धतींकडे आलो. आणि आमच्या समस्या नाहीशा झाल्या. म्हणून, अहवाल सुमारे सहा महिन्यांपूर्वी जाहीर करण्यात आला होता, जेव्हा हे सर्व माझ्या डोक्यात ताजे होते आणि मला ते सर्व चांगले आठवत होते.

अहवाल तयार करताना, मी आधीच जुने पोस्टमॉर्टेम उभे केले, नोंदी पाहिल्या. आणि समस्यांच्या विश्लेषणादरम्यान काही तपशील विसरले जाऊ शकतात, किंवा काही तपशील पूर्णपणे तपासले जाऊ शकत नाहीत, त्यामुळे काही ठिकाणी असे दिसते की समस्या पूर्णपणे विचारात घेतल्या जात नाहीत किंवा काही माहितीची कमतरता आहे. आणि म्हणून मी तुम्हाला या क्षणासाठी माफ करण्यास सांगतो.

Patroni म्हणजे काय?

• हा HA बांधण्यासाठी एक टेम्पलेट आहे. दस्तऐवजीकरणात असेच म्हटले आहे. आणि माझ्या दृष्टिकोनातून, हे एक अतिशय योग्य स्पष्टीकरण आहे. Patroni ही चांदीची गोळी नाही जी तुमच्या सर्व समस्या सोडवेल, म्हणजेच तुम्हाला ते कार्य करण्यासाठी आणि फायदे मिळवून देण्यासाठी प्रयत्न करणे आवश्यक आहे.
• ही एक एजंट सेवा आहे जी प्रत्येक डेटाबेस सेवेवर स्थापित केली जाते आणि आपल्या पोस्टग्रेससाठी एक प्रकारची इनिट सिस्टम आहे. हे पोस्टग्रेस सुरू करते, थांबते, रीस्टार्ट करते, पुन्हा कॉन्फिगर करते आणि तुमच्या क्लस्टरचे टोपोलॉजी बदलते.
• त्यानुसार, क्लस्टरची स्थिती संग्रहित करण्यासाठी, त्याचे वर्तमान प्रतिनिधित्व, जसे दिसते तसे, काही प्रकारचे स्टोरेज आवश्यक आहे. आणि या दृष्टिकोनातून, संरक्षकांनी बाह्य प्रणालीमध्ये राज्य संचयित करण्याचा मार्ग स्वीकारला. ही एक वितरित कॉन्फिगरेशन स्टोरेज सिस्टम आहे. हे Etcd, Consul, ZooKeeper किंवा kubernetes Etcd असू शकते, म्हणजे यापैकी एक पर्याय.
• आणि Patroni चे एक वैशिष्ट्य म्हणजे तुम्ही ऑटोफायलर बॉक्समधून बाहेर काढता, तो सेट करूनच. आम्ही तुलना करण्यासाठी Repmgr घेतल्यास, तेथे फाइलर समाविष्ट केला जातो. Repmgr सह, आम्हाला एक स्विचओव्हर मिळेल, परंतु आम्हाला ऑटोफायलर हवा असेल तर आम्हाला ते अतिरिक्त कॉन्फिगर करावे लागेल. Patroni कडे आधीपासूनच एक ऑटोफायलर आहे.
• आणि इतर अनेक गोष्टी आहेत. उदाहरणार्थ, कॉन्फिगरेशनची देखभाल, नवीन प्रतिकृती ओतणे, बॅकअप इ. परंतु हे अहवालाच्या व्याप्तीच्या बाहेर आहे, मी याबद्दल बोलणार नाही.

आणि एक छोटासा परिणाम असा आहे की Patroni चे मुख्य कार्य म्हणजे एक ऑटोफाईल चांगल्या आणि विश्वासार्हपणे करणे जेणेकरुन आमचे क्लस्टर कार्यरत राहील आणि ऍप्लिकेशनला क्लस्टर टोपोलॉजीमधील बदल लक्षात येणार नाहीत.

पण जेव्हा आम्ही Patroni वापरायला सुरुवात करतो, तेव्हा आमची प्रणाली थोडी अधिक क्लिष्ट होते. जर पूर्वी आमच्याकडे Postgres असेल, तर Patroni वापरताना आम्हाला Patroni स्वतः मिळतो, आम्हाला DCS मिळतो जिथे स्टेट स्टोर केले जाते. आणि हे सर्व कसेतरी कार्य करावे लागेल. मग काय चूक होऊ शकते?

खंडित होऊ शकते:

• पोस्टग्रेस खंडित होऊ शकते. हे मास्टर किंवा प्रतिकृती असू शकते, त्यापैकी एक अयशस्वी होऊ शकतो.
• पतरोनि स्वतः खंडित होऊ शकते.
• DCS जेथे राज्य संग्रहित आहे ते खंडित होऊ शकते.
• आणि नेटवर्क खंडित होऊ शकते.

हे सर्व मुद्दे मी अहवालात विचारात घेईन.

केसेसमध्ये अनेक घटकांचा समावेश आहे या दृष्टिकोनातून नव्हे तर ते अधिक गुंतागुंतीचे झाल्यामुळे मी केसेसचा विचार करेन. आणि व्यक्तिनिष्ठ भावनांच्या दृष्टिकोनातून, हे केस माझ्यासाठी कठीण होते, ते वेगळे करणे कठीण होते ... आणि उलट, काही केस हलके होते आणि ते वेगळे करणे सोपे होते.

आणि पहिला केस सर्वात सोपा आहे. जेव्हा आम्ही डेटाबेस क्लस्टर घेतला आणि त्याच क्लस्टरवर आमचे DCS स्टोरेज तैनात केले तेव्हा ही परिस्थिती आहे. ही सर्वात सामान्य चूक आहे. आर्किटेक्चर बांधण्यात ही चूक आहे, म्हणजे एकाच ठिकाणी वेगवेगळे घटक एकत्र करणे.

तर, एक फाइलर होता, चला काय झाले ते हाताळण्यासाठी जाऊया.

आणि येथे आम्हाला स्वारस्य आहे की फाइलर कधी झाला. म्हणजेच, जेव्हा क्लस्टर स्थिती बदलली तेव्हा आम्हाला या क्षणात स्वारस्य आहे.

परंतु फाइलर नेहमीच तात्कालिक नसतो, म्हणजे त्याला वेळेचे कोणतेही एकक लागत नाही, त्याला विलंब होऊ शकतो. ते दीर्घकाळ टिकू शकते.

म्हणून, त्याची प्रारंभ वेळ आणि समाप्ती वेळ आहे, म्हणजे ती एक सतत घटना आहे. आणि आम्ही सर्व इव्हेंट्सला तीन मध्यांतरांमध्ये विभागतो: आमच्याकडे फाइलरच्या आधी, फाइलर दरम्यान आणि फाइलर नंतर वेळ आहे. म्हणजेच, आम्ही या टाइमलाइनमधील सर्व घटनांचा विचार करतो.

आणि पहिली गोष्ट, जेव्हा फाइलर घडला तेव्हा आम्ही काय घडले याचे कारण शोधतो, फाइलर कशामुळे घडला याचे कारण काय होते.

आम्ही लॉग पाहिल्यास, ते क्लासिक पॅट्रोनी लॉग असतील. तो आम्हाला सांगतो की सर्व्हर मास्टर झाला आहे आणि मास्टरची भूमिका या नोडमध्ये गेली आहे. येथे ते हायलाइट केले आहे.

पुढे, आपल्याला हे समजून घेणे आवश्यक आहे की फाइलर का घडले, म्हणजे कोणत्या घटना घडल्या ज्यामुळे मुख्य भूमिका एका नोडमधून दुस-या नोडमध्ये गेली. आणि या प्रकरणात, सर्वकाही सोपे आहे. आम्हाला स्टोरेज सिस्टमशी संवाद साधताना त्रुटी आली आहे. मास्टरला समजले की तो डीसीएस बरोबर काम करू शकत नाही, म्हणजेच परस्परसंवादात काही प्रकारची समस्या आहे. आणि तो म्हणतो की तो यापुढे मास्टर होऊ शकत नाही आणि राजीनामा देतो. ही ओळ "डिमोटेड सेल्फ" हेच सांगते.

जर आपण फाइलरच्या आधीच्या घटना पाहिल्या तर, विझार्ड चालू ठेवण्यासाठी समस्या असलेली कारणे आपण तेथे पाहू शकतो.

आम्ही Patroni लॉग पाहिल्यास, आम्हाला दिसेल की आमच्याकडे बर्‍याच त्रुटी आहेत, कालबाह्यता आहेत, म्हणजे Patroni एजंट DCS सोबत काम करू शकत नाही. या प्रकरणात, हा कॉन्सुल एजंट आहे, जो पोर्ट 8500 वर संप्रेषण करत आहे.

आणि येथे समस्या अशी आहे की Patroni आणि डेटाबेस एकाच होस्टवर चालत आहेत. आणि त्याच नोडवर कॉन्सुल सर्व्हर लाँच केले गेले. सर्व्हरवर लोड तयार करून, आम्ही कॉन्सुल सर्व्हरसाठी समस्या निर्माण केल्या. त्यांच्यात नीट संवाद साधता येत नव्हता.

काही काळानंतर, जेव्हा भार कमी झाला, तेव्हा आमच्या संरक्षकांना पुन्हा एजंटांशी संवाद साधता आला. सामान्य कामकाज पुन्हा सुरू झाले. आणि तोच Pgdb-2 सर्व्हर पुन्हा मास्टर झाला. म्हणजेच, एक लहान फ्लिप होता, ज्यामुळे नोडने मास्टरच्या अधिकारांचा राजीनामा दिला आणि नंतर त्यांना पुन्हा ताब्यात घेतले, म्हणजेच सर्वकाही जसे होते तसे परत आले.

आणि हा खोटा अलार्म मानला जाऊ शकतो किंवा पटरोनीने सर्व काही ठीक केले असे मानले जाऊ शकते. म्हणजेच क्लस्टरची स्थिती आपण राखू शकत नाही हे त्याच्या लक्षात आले आणि त्याने आपला अधिकार काढून टाकला.

आणि येथे समस्या उद्भवली कारण कॉन्सुल सर्व्हर बेस सारख्याच हार्डवेअरवर आहेत. त्यानुसार, कोणताही भार: तो डिस्क किंवा प्रोसेसरवरील भार असला तरीही, ते कॉन्सुल क्लस्टरसह परस्परसंवादावर देखील परिणाम करते.

आणि आम्ही ठरवले की एकत्र राहायचे नाही, आम्ही कॉन्सुलसाठी स्वतंत्र क्लस्टर वाटप केले. आणि Patroni आधीच एका वेगळ्या कॉन्सुलसोबत काम करत होता, म्हणजेच एक वेगळा पोस्टग्रेस क्लस्टर होता, वेगळा कॉन्सुल क्लस्टर होता. या सर्व गोष्टी कशा सोबत ठेवायच्या आणि कशा ठेवायच्या याची ही प्राथमिक सूचना आहे जेणेकरून ती एकत्र राहू नये.

एक पर्याय म्हणून, तुम्ही ttl, loop_wait, retry_timeout हे पॅरामीटर्स ट्विस्ट करू शकता, म्हणजेच हे पॅरामीटर्स वाढवून या शॉर्ट-टर्म लोड पीकवर टिकून राहण्याचा प्रयत्न करा. परंतु हा सर्वात योग्य पर्याय नाही, कारण हा भार बराच काळ असू शकतो. आणि आपण या पॅरामीटर्सच्या या मर्यादेच्या पलीकडे जाऊ. आणि हे कदाचित खरोखर मदत करणार नाही.

पहिली समस्या, जसे आपण समजता, सोपी आहे. आम्ही बेससह DCS घेतले आणि ठेवले, आम्हाला एक समस्या आली.

दुसरी समस्या पहिल्यासारखीच आहे. हे असेच आहे की आम्हाला पुन्हा DCS प्रणालीसह इंटरऑपरेबिलिटी समस्या आहेत.

आम्ही लॉग पाहिल्यास, आम्हाला दिसेल की आमच्याकडे पुन्हा एक संप्रेषण त्रुटी आहे. आणि Patroni म्हणतो की मी DCS शी संवाद साधू शकत नाही म्हणून वर्तमान मास्टर प्रतिकृती मोडमध्ये जातो.

जुना मास्टर एक प्रतिकृती बनतो, येथे संरक्षक कार्य करतो, जसे ते असावे. हे व्यवहार लॉग रिवाइंड करण्यासाठी pg_rewind चालवते आणि नंतर नवीन मास्टरशी संपर्क साधण्यासाठी नवीन मास्टरशी कनेक्ट होते. येथे Patroni बाहेर काम, तो पाहिजे.

येथे आपल्याला फाइलरच्या आधीचे स्थान शोधणे आवश्यक आहे, म्हणजे त्या त्रुटी ज्यामुळे आम्हाला फाइलर आला. आणि या संदर्भात, Patroni लॉग काम करण्यासाठी अगदी सोयीस्कर आहेत. तो ठराविक अंतराने तेच संदेश लिहितो. आणि जर आपण या लॉग्समधून पटकन स्क्रोल करायला सुरुवात केली, तर आपल्याला लॉगमधून दिसेल की लॉग बदलले आहेत, म्हणजे काही समस्या सुरू झाल्या आहेत. आम्ही पटकन या ठिकाणी परतलो, काय होते ते पहा.

आणि सामान्य परिस्थितीत, लॉग असे काहीतरी दिसतात. लॉकच्या मालकाची तपासणी केली जाते. आणि जर मालक, उदाहरणार्थ, बदलला असेल, तर काही घटना घडू शकतात ज्यांना पॅट्रोनीने प्रतिसाद दिला पाहिजे. पण या प्रकरणात आम्ही ठीक आहोत. ज्या ठिकाणी त्रुटी सुरू झाल्या त्या ठिकाणाचा शोध घेत आहोत.

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

फाइलरच्या वेळेची आणि कॉन्सुल लॉगमधील वेळ यांची ढोबळमानाने तुलना केल्यास, आम्ही पाहतो की कॉन्सुल क्लस्टरमधील आमच्या शेजाऱ्यांना कॉन्सुल क्लस्टरच्या इतर सदस्यांच्या अस्तित्वावर शंका येऊ लागली.

आणि जर तुम्ही इतर कॉन्सुल एजंट्सच्या नोंदी पाहिल्या तर तुम्हाला हे देखील दिसेल की तिथे काही प्रकारचे नेटवर्क कोलॅप्स चालू आहे. आणि कॉन्सुल क्लस्टरचे सर्व सदस्य एकमेकांच्या अस्तित्वावर शंका घेतात. आणि फाइलरसाठी ही प्रेरणा होती.

या त्रुटींपूर्वी काय घडले ते आपण पाहिल्यास, आपण पाहू शकता की सर्व प्रकारच्या त्रुटी आहेत, उदाहरणार्थ, अंतिम मुदत, आरपीसी कमी झाली, म्हणजे, कॉन्सुल क्लस्टर सदस्यांच्या परस्परसंवादात स्पष्टपणे काही समस्या आहेत. .

नेटवर्क दुरुस्त करणे हे सर्वात सोपे उत्तर आहे. पण व्यासपीठावर उभं राहून माझ्यासाठी हे सांगणं सोपं आहे. परंतु परिस्थिती अशी आहे की नेटवर्क दुरुस्त करणे ग्राहकांना नेहमीच परवडत नाही. तो कदाचित डीसीमध्ये राहतो आणि नेटवर्क दुरुस्त करू शकत नाही, उपकरणांवर परिणाम करू शकत नाही. आणि म्हणून इतर काही पर्याय आवश्यक आहेत.

पर्याय आहेत:

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

मला वाटते की Patroni वापरणारे अनेकजण या आदेशाशी परिचित आहेत.

ही कमांड क्लस्टरची सद्यस्थिती दर्शवते. आणि पहिल्या दृष्टीक्षेपात, हे चित्र सामान्य वाटू शकते. आमच्याकडे मास्टर आहे, आमच्याकडे एक प्रतिकृती आहे, प्रतिकृती अंतर नाही. परंतु या क्लस्टरमध्ये दोन नव्हे तर तीन नोड्स असावेत हे कळेपर्यंत हे चित्र सामान्य आहे.

त्यानुसार, एक ऑटोफाइल होती. आणि या ऑटोफाइल नंतर, आमची प्रतिकृती गायब झाली. ती का गायब झाली हे शोधून तिला परत आणले पाहिजे, तिला पुनर्संचयित केले पाहिजे. आणि आम्ही पुन्हा लॉगवर जातो आणि आमच्याकडे ऑटो-फाइलओव्हर का होते ते पाहतो.

या प्रकरणात, दुसरी प्रतिकृती मास्टर बनली. इथे सर्व ठीक आहे.

आणि जी प्रतिकृती खाली पडली आणि जी क्लस्टरमध्ये नाही ती पाहण्याची गरज आहे. आम्ही Patroni लॉग उघडतो आणि पाहतो की pg_rewind स्टेजवर क्लस्टरशी कनेक्ट होण्याच्या प्रक्रियेदरम्यान आम्हाला समस्या आली होती. क्लस्टरशी कनेक्ट करण्यासाठी, तुम्हाला व्यवहार लॉग रिवाइंड करणे आवश्यक आहे, मास्टरकडून आवश्यक व्यवहार लॉगची विनंती करा आणि मास्टरशी संपर्क साधण्यासाठी त्याचा वापर करा.

या प्रकरणात, आमच्याकडे व्यवहार लॉग नाही आणि प्रतिकृती सुरू होऊ शकत नाही. त्यानुसार, आम्ही एका त्रुटीसह पोस्टग्रेस थांबवतो. आणि म्हणून ते क्लस्टरमध्ये नाही.

ते क्लस्टरमध्ये का नाही आणि लॉग का नव्हते हे समजून घेणे आवश्यक आहे. आम्ही नवीन मास्टरकडे जातो आणि त्याच्याकडे लॉगमध्ये काय आहे ते पाहतो. असे दिसून आले की जेव्हा pg_rewind केले गेले तेव्हा एक चेकपॉईंट आली. आणि काही जुन्या व्यवहार नोंदींचे नाव बदलण्यात आले. जेव्हा जुन्या मास्टरने नवीन मास्टरशी कनेक्ट करण्याचा प्रयत्न केला आणि या लॉगची चौकशी केली, तेव्हा ते आधीच पुनर्नामित केले गेले होते, ते अस्तित्वात नव्हते.

जेव्हा या घटना घडल्या तेव्हा मी टाइमस्टॅम्पची तुलना केली. आणि तेथे फरक अक्षरशः 150 मिलिसेकंदांचा आहे, म्हणजेच चेकपॉईंट 369 मिलिसेकंदमध्ये पूर्ण झाला, डब्ल्यूएएल विभागांचे नाव बदलले गेले. आणि अक्षरशः 517 मध्ये, 150 मिलिसेकंदांनंतर, जुन्या प्रतिकृतीवर रिवाइंड सुरू झाले. म्हणजेच, आमच्यासाठी अक्षरशः 150 मिलिसेकंद पुरेसे होते जेणेकरून प्रतिकृती कनेक्ट होऊ शकत नाही आणि कमाई करू शकत नाही.

पर्याय काय आहेत?

आम्ही सुरुवातीला प्रतिकृती स्लॉट वापरले. आम्हाला ते चांगले वाटले. जरी ऑपरेशनच्या पहिल्या टप्प्यावर आम्ही स्लॉट बंद केले. आम्हाला असे वाटले की जर स्लॉट्समध्ये भरपूर डब्ल्यूएएल विभाग जमा झाले तर आम्ही मास्टर सोडू शकतो. तो पडेल. आम्ही काही काळ स्लॉटशिवाय त्रास सहन केला. आणि आम्हाला समजले की आम्हाला स्लॉटची आवश्यकता आहे, आम्ही स्लॉट परत केले.

परंतु येथे एक समस्या आहे, की जेव्हा मास्टर प्रतिकृतीकडे जातो तेव्हा तो स्लॉट हटवतो आणि स्लॉटसह WAL विभाग हटवतो. आणि ही समस्या दूर करण्यासाठी, आम्ही wal_keep_segments पॅरामीटर वाढवण्याचा निर्णय घेतला. हे 8 विभागांमध्ये डीफॉल्ट आहे. आम्ही ते 1 पर्यंत वाढवले ​​आणि आमच्याकडे किती मोकळी जागा आहे ते पाहिले. आणि आम्ही wal_keep_segments साठी 000 gigabytes दान केले. म्हणजेच, स्विच करताना, आमच्याकडे नेहमी सर्व नोड्सवर 16 गीगाबाइट्स व्यवहार लॉगचा राखीव असतो.

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

आमच्याकडे उत्पादनाचा आधार आहे. तेथे आधीच प्रकल्प प्रगतीपथावर आहेत.

एक फाइलर होता. आम्ही आत गेलो आणि पाहिले - सर्व काही व्यवस्थित आहे, प्रतिकृती जागेवर आहेत, प्रतिकृती अंतर नाही. लॉगमध्ये एकतर त्रुटी नाहीत, सर्व काही व्यवस्थित आहे.

उत्पादन कार्यसंघ म्हणतो की काही डेटा असावा, परंतु आम्ही तो एका स्त्रोतावरून पाहतो, परंतु आम्हाला तो डेटाबेसमध्ये दिसत नाही. आणि त्यांचे काय झाले हे समजून घेतले पाहिजे.

हे स्पष्ट आहे की pg_rewind त्यांना चुकले. आम्हाला हे लगेच समजले, पण काय होते ते पाहायला गेलो.

लॉगमध्ये, आम्ही नेहमी शोधू शकतो की फाइलर कधी घडला, कोण मास्टर बनला आणि आम्ही ठरवू शकतो की जुना मास्टर कोण होता आणि त्याला कधी प्रतिकृती बनवायची होती, म्हणजेच आम्हाला व्यवहार लॉगची रक्कम शोधण्यासाठी या लॉगची आवश्यकता आहे. हरवला.

आमच्या जुन्या मास्टरने रीबूट केले आहे. आणि Patroni ऑटोरन मध्ये नोंदणीकृत होते. लाँच केली पटरोनी. त्यानंतर त्यांनी पोस्टग्रेस सुरू केले. अधिक स्पष्टपणे, Postgres सुरू करण्यापूर्वी आणि त्याची प्रतिकृती बनवण्यापूर्वी, Patroni ने pg_rewind प्रक्रिया सुरू केली. त्यानुसार, त्याने व्यवहार नोंदींचा काही भाग पुसून टाकला, नवीन डाउनलोड केले आणि कनेक्ट केले. येथे संरक्षकांनी हुशारीने काम केले, म्हणजेच अपेक्षेप्रमाणे. क्लस्टर पुनर्संचयित केले गेले आहे. आमच्याकडे 3 नोड्स होते, फाइलर 3 नोड्स नंतर - सर्व काही छान आहे.

आम्ही काही डेटा गमावला आहे. आणि आपण किती गमावले हे समजून घेतले पाहिजे. आम्ही फक्त तो क्षण शोधत आहोत जेव्हा आम्हाला रिवाइंड होते. अशा जर्नलच्या नोंदींमध्ये आपण ते शोधू शकतो. रिवाइंड सुरू झाले, तिथे काहीतरी केले आणि संपले.

आम्हाला व्यवहार लॉगमध्ये स्थान शोधण्याची आवश्यकता आहे जिथे जुन्या मास्टरने सोडले होते. या प्रकरणात, हे चिन्ह आहे. आणि आपल्याला दुसर्‍या चिन्हाची आवश्यकता आहे, म्हणजे, जुना मास्टर नवीनपेक्षा भिन्न आहे.

आम्ही नेहमीच्या pg_wal_lsn_diff घेतो आणि या दोन गुणांची तुलना करतो. आणि या प्रकरणात, आम्हाला 17 मेगाबाइट्स मिळतात. बरेच किंवा थोडे, प्रत्येकजण स्वत: साठी निर्णय घेतो. कारण कोणासाठी 17 मेगाबाइट जास्त नाही, तर कोणासाठी ते खूप आणि अस्वीकार्य आहे. येथे, प्रत्येक व्यक्ती व्यवसायाच्या गरजांनुसार स्वतःसाठी ठरवते.

पण आम्ही स्वतःसाठी काय शोधले आहे?

प्रथम, आपण स्वत: साठी निर्णय घेतला पाहिजे - सिस्टम रीबूट केल्यानंतर ऑटोस्टार्ट होण्यासाठी आम्हाला नेहमी Patroni आवश्यक आहे का? बरेचदा असे होते की आपल्याला जुन्या मास्टरकडे जावे लागेल, तो किती दूर गेला आहे ते पहा. कदाचित व्यवहार लॉगच्या विभागांची तपासणी करा, तेथे काय आहे ते पहा. आणि आम्ही हा डेटा गमावू शकतो की नाही हे समजून घेण्यासाठी किंवा हा डेटा बाहेर काढण्यासाठी आम्हाला जुना मास्टर स्टँडअलोन मोडमध्ये चालवावा लागेल का.

आणि त्यानंतरच आपण हे ठरवले पाहिजे की आपण हा डेटा टाकून देऊ शकतो की आपण तो पुनर्संचयित करू शकतो, हा नोड आपल्या क्लस्टरशी प्रतिकृती म्हणून कनेक्ट करू शकतो.

या व्यतिरिक्त, "maximum_lag_on_failover" पॅरामीटर आहे. डीफॉल्टनुसार, माझी मेमरी मला सेवा देत असल्यास, या पॅरामीटरचे मूल्य 1 मेगाबाइट आहे.

तो कसा काम करतो? जर आमची प्रतिकृती प्रतिकृती अंतरामध्ये 1 मेगाबाइट डेटाने मागे असेल, तर ही प्रतिकृती निवडणुकीत भाग घेणार नाही. आणि जर अचानक फाईलओव्हर झाला तर कोणत्या प्रतिकृती मागे पडल्या आहेत हे पटरोनी पाहते. जर ते मोठ्या संख्येने व्यवहार नोंदींमध्ये मागे असतील तर ते मास्टर बनू शकत नाहीत. हे एक अतिशय चांगले सुरक्षा वैशिष्ट्य आहे जे तुम्हाला भरपूर डेटा गमावण्यापासून प्रतिबंधित करते.

पण यात एक अडचण आहे की Patroni क्लस्टर आणि DCS मध्ये रिप्लिकेशन लॅग ठराविक अंतराने अपडेट केले जाते. माझ्या मते 30 सेकंद हे डीफॉल्ट टीटीएल मूल्य आहे.

त्यानुसार, अशी परिस्थिती असू शकते की DCS मध्ये प्रतिकृतींसाठी एक प्रतिकृती अंतर आहे, परंतु प्रत्यक्षात एक पूर्णपणे भिन्न अंतर असू शकतो किंवा अजिबात अंतर असू शकत नाही, म्हणजे ही गोष्ट वास्तविक वेळ नाही. आणि हे नेहमीच वास्तविक चित्र प्रतिबिंबित करत नाही. आणि त्यावर फॅन्सी लॉजिक करणे योग्य नाही.

आणि नुकसानीचा धोका नेहमीच राहतो. आणि सर्वात वाईट बाबतीत, एक सूत्र, आणि सरासरी प्रकरणात, दुसरे सूत्र. म्हणजेच, जेव्हा आपण Patroni च्या अंमलबजावणीची योजना आखतो आणि आपण किती डेटा गमावू शकतो याचे मूल्यमापन करतो, तेव्हा आपण या सूत्रांवर अवलंबून राहून आपण किती डेटा गमावू शकतो याची अंदाजे कल्पना केली पाहिजे.

आणि एक चांगली बातमी आहे. जेव्हा जुना मास्टर पुढे जातो तेव्हा तो काही पार्श्वभूमी प्रक्रियेमुळे पुढे जाऊ शकतो. म्हणजेच, एक प्रकारचा ऑटोव्हॅक्यूम होता, त्याने डेटा लिहिला, व्यवहार लॉगमध्ये जतन केला. आणि आम्ही सहजपणे दुर्लक्ष करू शकतो आणि हा डेटा गमावू शकतो. यामध्ये कोणतीही अडचण नाही.

आणि जास्तीत जास्त_लॅग_ऑन_फेलओव्हर सेट केले असल्यास आणि फाइलर आला असल्यास लॉग कसे दिसतात आणि तुम्हाला नवीन मास्टर निवडण्याची आवश्यकता आहे. प्रतिकृती स्वतःला निवडणुकीत भाग घेण्यास असमर्थ असल्याचे मूल्यांकन करते. आणि ती नेत्याच्या शर्यतीत सहभागी होण्यास नकार देते. आणि ती नवीन मास्टरची निवड होण्याची वाट पाहत आहे, जेणेकरून ती त्याच्याशी कनेक्ट होऊ शकेल. डेटा हानीविरूद्ध हे अतिरिक्त उपाय आहे.

येथे आमच्याकडे एक उत्पादन संघ आहे ज्याने लिहिले की त्यांच्या उत्पादनास पोस्टग्रेसमध्ये समस्या येत आहेत. त्याच वेळी, मास्टरमध्येच प्रवेश केला जाऊ शकत नाही, कारण तो SSH द्वारे उपलब्ध नाही. आणि ऑटोफाइल देखील होत नाही.

या होस्टला रीबूट करण्यास भाग पाडले गेले. रीबूट केल्यामुळे, एक स्वयं-फाइल घडली, जरी मला आता समजल्याप्रमाणे मॅन्युअल स्वयं-फाइल करणे शक्य होते. आणि रीबूट केल्यानंतर, आम्ही सध्याच्या मास्टरकडे काय होते ते आधीच पाहणार आहोत.

त्याच वेळी, आम्हाला आधीच माहित होते की आम्हाला डिस्क्समध्ये समस्या आहेत, म्हणजेच कोठे खोदायचे आणि काय शोधायचे याचे निरीक्षण करण्यापासून आम्हाला आधीच माहित होते.

आम्ही पोस्टग्रेस लॉगमध्ये गेलो, तिथे काय चालले आहे ते पाहू लागलो. आम्ही कमिट पाहिले जे तेथे एक, दोन, तीन सेकंद टिकतात, जे अजिबात सामान्य नाही. आम्ही पाहिले की आमचे ऑटोव्हॅक्यूम खूप हळू आणि विचित्रपणे सुरू होते. आणि आम्ही डिस्कवर तात्पुरत्या फाइल्स पाहिल्या. म्हणजेच, हे सर्व डिस्कसह समस्यांचे सूचक आहेत.

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

आणि या प्रकरणात, Patroni आम्हाला कोणत्याही प्रकारे मदत करणार नाही, कारण Patroni कडे सर्व्हरची स्थिती, डिस्कच्या स्थितीवर लक्ष ठेवण्याचे काम नाही. आणि आपण बाह्य निरीक्षणाद्वारे अशा परिस्थितींचे निरीक्षण केले पाहिजे. आम्ही त्वरीत बाह्य निरीक्षणामध्ये डिस्क मॉनिटरिंग जोडले.

आणि असा विचार आला - कुंपण किंवा वॉचडॉग सॉफ्टवेअर आम्हाला मदत करू शकेल? आम्हाला वाटले की त्यांनी या प्रकरणात आमची क्वचितच मदत केली असेल, कारण समस्यांच्या काळात Patroni DCS क्लस्टरशी संवाद साधत राहिला आणि त्यांना कोणतीही समस्या दिसली नाही. म्हणजेच, DCS आणि Patroni च्या दृष्टिकोनातून, क्लस्टरमध्ये सर्वकाही ठीक होते, जरी खरं तर डिस्कमध्ये समस्या होत्या, डेटाबेसच्या उपलब्धतेमध्ये समस्या होत्या.

माझ्या मते, ही एक विचित्र समस्या आहे ज्यावर मी बर्याच काळापासून संशोधन केले आहे, मी बरेच लॉग वाचले आहेत, पुन्हा निवडले आहेत आणि त्याला क्लस्टर सिम्युलेटर म्हटले आहे.

अडचण अशी होती की जुने मास्टर सामान्य प्रतिकृती बनू शकले नाही, म्हणजे पॅट्रोनीने ते सुरू केले, पॅट्रोनीने दाखवले की हा नोड एक प्रतिकृती म्हणून उपस्थित होता, परंतु त्याच वेळी ती सामान्य प्रतिकृती नव्हती. आता तुम्ही का बघाल. त्या समस्येच्या विश्लेषणातून मी हेच ठेवले आहे.

आणि हे सर्व कसे सुरू झाले? पूर्वीच्या समस्येप्रमाणेच, डिस्क ब्रेकसह ते सुरू झाले. आम्ही एक सेकंद, दोन साठी कमिट होते.

कनेक्शन तुटले होते, म्हणजे क्लायंट फाटले होते.

वेगवेगळ्या तीव्रतेचे अवरोध होते.

आणि, त्यानुसार, डिस्क उपप्रणाली फार प्रतिसाद देत नाही.

आणि माझ्यासाठी सर्वात रहस्यमय गोष्ट म्हणजे तात्काळ शटडाउन विनंती आली आहे. पोस्टग्रेसमध्ये तीन शटडाउन मोड आहेत:

• जेव्हा आम्ही सर्व क्लायंट स्वतःहून डिस्कनेक्ट होण्याची वाट पाहतो तेव्हा ते छान असते.
• जेव्हा आम्ही क्लायंटला डिस्कनेक्ट करण्यास भाग पाडतो तेव्हा वेगवान असतो कारण आम्ही बंद करणार आहोत.
• आणि तात्काळ. या प्रकरणात, तात्काळ क्लायंटला बंद करण्यास सांगत नाही, ते फक्त चेतावणीशिवाय बंद होते. आणि सर्व क्लायंटना, ऑपरेटिंग सिस्टम आधीच RST संदेश पाठवते (एक TCP संदेश जो कनेक्शनमध्ये व्यत्यय आला आहे आणि क्लायंटकडे पकडण्यासाठी आणखी काही नाही).

हा सिग्नल कोणी पाठवला? पोस्टग्रेस पार्श्वभूमी प्रक्रिया एकमेकांना असे सिग्नल पाठवत नाहीत, म्हणजेच हे किल-9 आहे. ते अशा गोष्टी एकमेकांना पाठवत नाहीत, ते फक्त अशा गोष्टींवर प्रतिक्रिया देतात, म्हणजे पोस्टग्रेसची ही आपत्कालीन रीस्टार्ट आहे. कोणी पाठवले, मला माहीत नाही.

मी "शेवटची" कमांड पाहिली आणि मला एक व्यक्ती दिसली ज्याने आमच्यासह या सर्व्हरमध्ये लॉग इन केले आहे, परंतु मला प्रश्न विचारण्यास लाजाळू वाटली. कदाचित ते मारले गेले -9. मला लॉगमध्ये किल -9 दिसेल, कारण पोस्टग्रेस म्हणतो की ते मारले -9, परंतु मला ते लॉगमध्ये दिसले नाही.

पुढे पाहिल्यावर, मी पाहिले की संरक्षकाने लॉगवर बराच वेळ लिहिले नाही - 54 सेकंद. आणि जर आपण दोन टाइमस्टॅम्पची तुलना केली तर सुमारे 54 सेकंदांपर्यंत कोणतेही संदेश नव्हते.

आणि या वेळी एक ऑटोफाइल होती. संरक्षकांनी येथे पुन्हा चांगले काम केले. आमचे जुने मास्तर उपलब्ध नव्हते, त्यांना काहीतरी झाले. आणि नवीन मास्टरची निवड सुरू झाली. येथे सर्व काही चांगले चालले. आमचा pgsql01 नवीन लीडर बनला आहे.

आमच्याकडे एक प्रतिकृती आहे जी मास्टर बनली आहे. आणि दुसरा प्रतिसाद आहे. आणि दुसऱ्या प्रतिकृतीत अडचणी आल्या. तिने पुन्हा कॉन्फिगर करण्याचा प्रयत्न केला. मला समजल्याप्रमाणे, तिने recovery.conf बदलण्याचा, पोस्टग्रेस रीस्टार्ट करण्याचा आणि नवीन मास्टरशी कनेक्ट करण्याचा प्रयत्न केला. ती प्रत्येक 10 सेकंदाला संदेश लिहिते की ती प्रयत्न करत आहे, परंतु ती यशस्वी होत नाही.

आणि या प्रयत्नांदरम्यान, जुन्या मास्टरकडे त्वरित-शटडाउन सिग्नल येतो. मास्टर पुन्हा सुरू आहे. आणि पुनर्प्राप्ती देखील थांबते कारण जुना मास्टर रीबूटमध्ये जातो. म्हणजेच, प्रतिकृती त्याच्याशी कनेक्ट होऊ शकत नाही, कारण ती शटडाउन मोडमध्ये आहे.

काही क्षणी, ते कार्य केले, परंतु प्रतिकृती सुरू झाली नाही.

माझा एकच अंदाज आहे की recovery.conf मध्ये एक जुना मुख्य पत्ता होता. आणि जेव्हा एक नवीन मास्टर दिसला, तेव्हा दुसरी प्रतिकृती अद्याप जुन्या मास्टरशी कनेक्ट करण्याचा प्रयत्न करीत आहे.

जेव्हा Patroni दुसऱ्या प्रतिकृतीवर सुरुवात केली, तेव्हा नोड सुरू झाला परंतु प्रतिकृती बनवू शकला नाही. आणि एक प्रतिकृती अंतर तयार झाला, जो असे काहीतरी दिसत होता. म्हणजेच तीनही नोड जागेवर होते, पण दुसरा नोड मागे पडला.

त्याच वेळी, जर तुम्ही लिहिलेल्या नोंदी पाहिल्या, तर तुम्हाला दिसेल की प्रतिकृती सुरू होऊ शकली नाही कारण व्यवहार लॉग भिन्न होते. आणि ते व्यवहार लॉग जे मास्टर ऑफर करतो, जे recovery.conf मध्ये निर्दिष्ट केले आहेत, फक्त आमच्या सध्याच्या नोडमध्ये बसत नाहीत.

आणि इथे मी चूक केली. आम्ही चुकीच्या मास्टरशी कनेक्ट करत आहोत या माझ्या गृहीतकाची चाचणी घेण्यासाठी मला recovery.conf मध्ये काय आहे ते पाहावे लागले. पण नंतर मी फक्त हे हाताळत होतो आणि ते मला घडले नाही, किंवा मी पाहिले की प्रतिकृती मागे पडली आहे आणि ती पुन्हा भरावी लागेल, म्हणजेच मी कसे तरी निष्काळजीपणे काम केले. हे माझे संयुक्त होते.

30 मिनिटांनंतर, प्रशासक आधीच आला, म्हणजे मी प्रतिकृतीवर Patroni पुन्हा सुरू केली. मी आधीच ते संपवले आहे, मला वाटले की ते पुन्हा भरावे लागेल. आणि मी विचार केला - मी Patroni रीस्टार्ट करेन, कदाचित काहीतरी चांगले होईल. वसुली सुरू झाली. आणि बेस अगदी उघडला, तो कनेक्शन स्वीकारण्यास तयार होता.

प्रतिकृती सुरू झाली आहे. पण एक मिनिटानंतर ती चुकून पडली की ट्रान्झॅक्शन लॉग तिच्यासाठी योग्य नाहीत.

मला वाटले की मी पुन्हा सुरू करू. मी Patroni पुन्हा रीस्टार्ट केले आणि मी Postgres रीस्टार्ट केले नाही, पण Patroni रीस्टार्ट केले या आशेने की तो डेटाबेसला जादूने सुरू करेल.

प्रतिकृती पुन्हा सुरू झाली, परंतु व्यवहार लॉगमधील गुण भिन्न होते, ते मागील प्रारंभ प्रयत्नासारखे नव्हते. प्रतिकृती पुन्हा थांबली. आणि संदेश आधीच थोडा वेगळा होता. आणि ते माझ्यासाठी फार माहितीपूर्ण नव्हते.

आणि मग मला असे घडते - जर मी पोस्टग्रेस रीस्टार्ट केले तर, यावेळी मी ट्रान्झॅक्शन लॉगमधील बिंदू थोडा पुढे हलविण्यासाठी वर्तमान मास्टरवर एक चेकपॉईंट बनविला जेणेकरून पुनर्प्राप्ती दुसर्‍या क्षणापासून सुरू होईल? शिवाय, आमच्याकडे अजूनही WAL चा साठा होता.

मी Patroni रीस्टार्ट केले, मास्टरवर दोन चेकपॉइंट्स केले, जेव्हा ते उघडले तेव्हा प्रतिकृतीवर दोन रीस्टार्ट पॉइंट्स केले. आणि त्याची मदत झाली. मी बराच काळ विचार केला की ते का मदत करते आणि ते कसे कार्य करते. आणि प्रतिकृती सुरू झाली. आणि प्रतिकृती आता फाटलेली नव्हती.

माझ्यासाठी अशी समस्या ही सर्वात रहस्यमय समस्यांपैकी एक आहे, ज्यावर मला अजूनही तेथे खरोखर काय घडले याबद्दल कोडे आहे.

येथे काय परिणाम आहेत? Patroni हेतूनुसार आणि कोणत्याही त्रुटीशिवाय काम करू शकते. परंतु त्याच वेळी, ही 100% हमी नाही की आमच्याबरोबर सर्व काही ठीक आहे. प्रतिकृती सुरू होऊ शकते, परंतु ती अर्ध-कार्यरत स्थितीत असू शकते आणि अनुप्रयोग अशा प्रतिकृतीसह कार्य करू शकत नाही, कारण जुना डेटा असेल.

आणि फाइलर नंतर, आपल्याला नेहमी क्लस्टरसह सर्वकाही व्यवस्थित आहे हे तपासण्याची आवश्यकता आहे, म्हणजेच, आवश्यक प्रतिकृती आहेत, प्रतिकृती अंतर नाही.

आणि आम्ही या समस्यांमधून जात असताना, मी शिफारसी करेन. मी त्यांना दोन स्लाइड्समध्ये एकत्र करण्याचा प्रयत्न केला. कदाचित, सर्व कथा दोन स्लाइड्समध्ये एकत्र केल्या जाऊ शकतात आणि फक्त सांगितल्या जाऊ शकतात.

जेव्हा तुम्ही Patroni वापरता तेव्हा तुमच्याकडे मॉनिटरिंग असणे आवश्यक आहे. ऑटोफाइलओव्हर केव्हा झाला हे तुम्हाला नेहमी माहित असले पाहिजे, कारण जर तुम्हाला माहित नसेल की तुमच्याकडे ऑटोफाइलओव्हर आहे, तर क्लस्टरवर तुमचे नियंत्रण नाही. आणि ते वाईट आहे.

प्रत्येक फाइलर नंतर, आम्हाला नेहमी स्वतः क्लस्टर तपासावे लागते. आम्‍हाला खात्री करणे आवश्‍यक आहे की आमच्याकडे नेहमी प्रतिकृतींची अद्ययावत संख्‍या असल्‍याची, प्रतिकृती अंतर नाही, प्रवाह प्रतिकृतीशी संबंधित लॉगमध्‍ये कोणत्याही त्रुटी नाहीत, Patroni सह, DCS प्रणालीसह.

ऑटोमेशन यशस्वीरित्या कार्य करू शकते, Patroni एक अतिशय चांगले साधन आहे. हे कार्य करू शकते, परंतु हे क्लस्टरला इच्छित स्थितीत आणणार नाही. आणि जर आम्हाला याबद्दल माहिती मिळाली नाही तर आम्ही अडचणीत येऊ.

आणि पात्रोनी चांदीची गोळी नाही. पोस्टग्रेस कसे कार्य करते, प्रतिकृती कशी कार्य करते आणि पॅट्रोनी पोस्टग्रेससह कसे कार्य करते आणि नोड्समधील संवाद कसा प्रदान केला जातो हे आम्हाला अद्याप समजून घेणे आवश्यक आहे. आपल्या हातांनी समस्यांचे निराकरण करण्यात सक्षम होण्यासाठी हे आवश्यक आहे.

मी निदानाच्या समस्येकडे कसे जाऊ? असे घडले की आम्ही वेगवेगळ्या क्लायंटसह काम करतो आणि कोणाकडेही ELK स्टॅक नाही आणि आम्हाला 6 कन्सोल आणि 2 टॅब उघडून लॉगची क्रमवारी लावावी लागेल. एका टॅबमध्ये, हे प्रत्येक नोडसाठी पॅट्रोनी लॉग आहेत, दुसऱ्या टॅबमध्ये, हे कॉन्सुल लॉग आहेत, किंवा आवश्यक असल्यास पोस्टग्रेस आहेत. याचे निदान करणे फार कठीण आहे.

मी कोणते मार्ग स्वीकारले आहेत? प्रथम, मी नेहमी पाहतो की फाइलर कधी आला आहे. आणि माझ्यासाठी हे पाणलोट आहे. फाइलरच्या आधी, फाइलर दरम्यान आणि फाइलर नंतर काय झाले ते मी पाहतो. फाइलओव्हरमध्ये दोन गुण आहेत: ही सुरुवात आणि समाप्ती वेळ आहे.

पुढे, मी फाइलरच्या आधीच्या घटनांसाठी लॉगमध्ये पाहतो, जे फाइलरच्या आधीचे होते, म्हणजे मी फाइलर का घडले याची कारणे शोधतो.

आणि हे काय झाले आणि भविष्यात काय केले जाऊ शकते हे समजून घेण्याचे एक चित्र देते जेणेकरुन अशी परिस्थिती उद्भवू नये (आणि परिणामी, फाइलर नाही).

आणि आम्ही सहसा कुठे पाहतो? मी बघतो:

• प्रथम, Patroni नोंदी करण्यासाठी.
• पुढे, पॅट्रोनी लॉगमध्ये काय सापडले यावर अवलंबून मी पोस्टग्रेस लॉग किंवा DCS लॉग पाहतो.
• आणि सिस्टम लॉग देखील कधीकधी फाइलर कशामुळे झाला याची समज देतात.

मला Patroni बद्दल कसे वाटते? पात्रोनीशी माझे खूप चांगले संबंध आहेत. माझ्या मते, हे आजचे सर्वोत्तम आहे. मला इतर अनेक उत्पादने माहित आहेत. हे Stolon, Repmgr, Pg_auto_failover, PAF आहेत. 4 साधने. मी ते सर्व प्रयत्न केले. पतरोनि माझा आवडता ।

जर त्यांनी मला विचारले: "मी Patroni शिफारस करतो?". मी हो म्हणेन, कारण मला पटरोनी आवडते. आणि मला वाटते की मी ते कसे शिजवायचे ते शिकले.

मी नमूद केलेल्या समस्यांव्यतिरिक्त Patroni सोबत इतर कोणत्या समस्या आहेत हे पाहण्यात तुम्हाला स्वारस्य असल्यास, तुम्ही नेहमी पेज पाहू शकता समस्या GitHub वर. अनेक वेगवेगळ्या कथा आहेत आणि अनेक मनोरंजक मुद्दे तिथे चर्चिले जातात. आणि परिणामी, काही बग ओळखले गेले आणि सोडवले गेले, म्हणजेच हे एक मनोरंजक वाचन आहे.

लोक स्वतःच्या पायावर गोळी झाडतात याबद्दल काही मनोरंजक कथा आहेत. अतिशय माहितीपूर्ण. तुम्ही वाचता आणि समजता की असे करणे आवश्यक नाही. मी स्वतःला खूण केली.

आणि अलेक्झांडर कुकुश्किन आणि अॅलेक्सी क्ल्युकिन यांना हा प्रकल्प विकसित केल्याबद्दल मी झालँडोचे खूप आभार मानू इच्छितो. अलेक्से क्ल्युकिन हे सह-लेखकांपैकी एक आहेत, तो यापुढे झालँडो येथे काम करत नाही, परंतु हे दोन लोक आहेत ज्यांनी या उत्पादनासह काम करण्यास सुरवात केली.

आणि मला वाटतं की Patroni ही खूप छान गोष्ट आहे. मला आनंद आहे की ती अस्तित्वात आहे, तिच्याबरोबर हे मनोरंजक आहे. आणि Patroni ला पॅच लिहिणाऱ्या सर्व योगदानकर्त्यांचे खूप खूप आभार. मला आशा आहे की Patroni वयानुसार अधिक प्रौढ, छान आणि कार्यक्षम होईल. हे आधीच कार्यरत आहे, परंतु मला आशा आहे की ते आणखी चांगले होईल. म्हणून, जर तुम्ही Patroni वापरण्याची योजना आखत असाल तर घाबरू नका. हा एक चांगला उपाय आहे, तो अंमलात आणला जाऊ शकतो आणि वापरला जाऊ शकतो.

इतकंच. तुम्हाला प्रश्न असतील तर विचारा.

प्रश्न

अहवालाबद्दल धन्यवाद! जर फाइलर नंतरही तुम्हाला तिकडे खूप काळजीपूर्वक पाहण्याची गरज आहे, तर आम्हाला स्वयंचलित फाइलरची आवश्यकता का आहे?

कारण ती नवीन गोष्ट आहे. आम्ही फक्त एक वर्ष तिच्यासोबत आहोत. सुरक्षित असणे चांगले. आम्‍हाला आत यायचे आहे आणि हे पाहायचे आहे की सर्वकाही खरोखरच हवे तसे झाले आहे. प्रौढांच्या अविश्वासाची ही पातळी आहे - दोनदा तपासणे आणि पाहणे चांगले आहे.

उदाहरणार्थ, आम्ही सकाळी गेलो आणि पाहिले, बरोबर?

सकाळी नाही, आम्ही सहसा ऑटोफाइलबद्दल जवळजवळ लगेच शिकतो. आम्हाला सूचना प्राप्त होतात, आम्ही पाहतो की एक ऑटोफाइल आली आहे. आम्ही लगेच जाऊन बघतो. मात्र या सर्व तपासण्या मॉनिटरिंगच्या पातळीवर आणल्या पाहिजेत. तुम्ही REST API द्वारे Patroni मध्ये प्रवेश केल्यास, एक इतिहास आहे. इतिहासानुसार तुम्ही फाइलर केव्हा घडले ते टाइमस्टॅम्प पाहू शकता. त्याआधारे निरीक्षण करता येते. आपण इतिहास पाहू शकता, किती घटना होत्या. आमच्याकडे अधिक इव्हेंट असल्यास, एक ऑटोफाइल आली आहे. तुम्ही जाऊन पाहू शकता. किंवा आमच्या मॉनिटरिंग ऑटोमेशनने तपासले की आमच्याकडे सर्व प्रतिकृती आहेत, तेथे कोणतेही अंतर नाही आणि सर्व काही ठीक आहे.

धन्यवाद!

छान कथेसाठी खूप खूप धन्यवाद! जर आपण डीसीएस क्लस्टर पोस्टग्रेस क्लस्टरपासून दूर कुठेतरी हलवले, तर या क्लस्टरला देखील वेळोवेळी सर्व्हिसिंग करणे आवश्यक आहे? DCS क्लस्टरचे काही भाग बंद करणे, त्यांच्यासोबत काहीतरी करणे इ. कोणत्या सर्वोत्तम पद्धती आहेत? ही संपूर्ण रचना कशी टिकते? आणि तुम्ही या गोष्टी कशा करता?

एका कंपनीसाठी, समस्यांचे मॅट्रिक्स तयार करणे आवश्यक होते, घटकांपैकी एक किंवा अनेक घटक अयशस्वी झाल्यास काय होते. या मॅट्रिक्सनुसार, आम्ही क्रमशः सर्व घटकांमधून जातो आणि हे घटक अयशस्वी झाल्यास परिस्थिती तयार करतो. त्यानुसार, प्रत्येक अयशस्वी परिस्थितीसाठी, तुमच्याकडे पुनर्प्राप्तीसाठी कृती योजना असू शकते. आणि DCS च्या बाबतीत, ते मानक पायाभूत सुविधांचा भाग म्हणून येते. आणि प्रशासक ते प्रशासित करतो, आणि आम्ही आधीच त्याचे व्यवस्थापन करणार्‍या प्रशासकांवर आणि अपघात झाल्यास त्याचे निराकरण करण्याच्या त्यांच्या क्षमतेवर अवलंबून आहोत. अजिबात DCS नसल्यास, आम्ही ते तैनात करतो, परंतु त्याच वेळी आम्ही त्याचे विशेष निरीक्षण करत नाही, कारण आम्ही पायाभूत सुविधांसाठी जबाबदार नाही, परंतु आम्ही कसे आणि कशाचे निरीक्षण करावे याबद्दल शिफारसी देतो.

म्हणजे, यजमानांसोबत काहीही करण्यापूर्वी मला Patroni अक्षम करणे, फाइलर अक्षम करणे, सर्वकाही अक्षम करणे आवश्यक आहे हे मला योग्यरित्या समजले आहे का?

आमच्याकडे DCS क्लस्टरमध्ये किती नोड्स आहेत यावर ते अवलंबून आहे. जर अनेक नोड्स असतील आणि जर आपण फक्त एक नोड (प्रतिकृती) अक्षम केला, तर क्लस्टर एक कोरम राखतो. आणि Patroni कार्यरत राहते. आणि काहीही ट्रिगर होत नाही. जर आमच्याकडे काही जटिल ऑपरेशन्स आहेत ज्या अधिक नोड्सवर परिणाम करतात, ज्याच्या अनुपस्थितीमुळे कोरम खराब होऊ शकतो, तर - होय, पॅट्रोनीला विराम देण्यास काही अर्थ आहे. यात एक संबंधित कमांड आहे - patronictl pause, patronictl resume. आम्ही फक्त विराम देतो आणि ऑटोफायलर त्यावेळी काम करत नाही. आम्ही DCS क्लस्टरवर देखभाल करतो, नंतर आम्ही विराम काढून घेतो आणि जगणे सुरू ठेवतो.

खूप खूप धन्यवाद!

तुमच्या अहवालाबद्दल खूप खूप धन्यवाद! डेटा गमावल्याबद्दल उत्पादन संघाला कसे वाटते?

उत्पादन कार्यसंघ काळजी करत नाहीत आणि संघ प्रमुख चिंतेत आहेत.

काय हमी आहेत?

हमीपत्रे फार कठीण आहेत. अलेक्झांडर कुकुश्किनचा अहवाल आहे “आरपीओ आणि आरटीओची गणना कशी करावी”, म्हणजे पुनर्प्राप्ती वेळ आणि आपण किती डेटा गमावू शकतो. मला वाटते की आपण या स्लाइड्स शोधून त्यांचा अभ्यास केला पाहिजे. माझ्या लक्षात येण्यापर्यंत, या गोष्टींची गणना कशी करायची यावर विशिष्ट पायऱ्या आहेत. आपण किती व्यवहार गमावू शकतो, किती डेटा गमावू शकतो. पर्याय म्हणून, आम्ही पॅट्रोनी स्तरावर सिंक्रोनस प्रतिकृती वापरू शकतो, परंतु ही दुधारी तलवार आहे: आमच्याकडे डेटाची विश्वासार्हता आहे किंवा आम्ही वेग गमावतो. सिंक्रोनस प्रतिकृती आहे, परंतु ते डेटा गमावण्यापासून 100% संरक्षणाची हमी देखील देत नाही.

अॅलेक्सी, छान अहवालासाठी धन्यवाद! शून्य पातळी संरक्षणासाठी Patroni वापरण्याचा काही अनुभव आहे? म्हणजे, समकालिक स्टँडबायच्या संयोगाने? हा पहिला प्रश्न आहे. आणि दुसरा प्रश्न. तुम्ही वेगवेगळे उपाय वापरले आहेत. आम्ही Repmgr वापरले, परंतु ऑटोफायलरशिवाय, आणि आता आम्ही ऑटोफायलर समाविष्ट करण्याचा विचार करत आहोत. आणि आम्ही Patroni हा पर्यायी उपाय मानतो. Repmgr च्या तुलनेत फायदे म्हणून तुम्ही काय म्हणू शकता?

पहिला प्रश्न सिंक्रोनस प्रतिकृतींबद्दल होता. येथे कोणीही समकालिक प्रतिकृती वापरत नाही, कारण प्रत्येकजण घाबरलेला आहे (अनेक क्लायंट आधीच ते वापरत आहेत, तत्त्वतः, त्यांना कार्यप्रदर्शन समस्या लक्षात आल्या नाहीत - स्पीकरची नोंद). परंतु आम्ही स्वतःसाठी एक नियम विकसित केला आहे की समकालिक प्रतिकृती क्लस्टरमध्ये किमान तीन नोड्स असावेत, कारण आमच्याकडे दोन नोड्स असल्यास आणि जर मास्टर किंवा प्रतिकृती अयशस्वी झाल्यास, पॅट्रोनी या नोडला स्टँडअलोन मोडवर स्विच करते जेणेकरून अनुप्रयोग चालू राहील. काम. या प्रकरणात, डेटा गमावण्याचा धोका आहे.

दुसऱ्या प्रश्नाबाबत, आम्ही Repmgr चा वापर केला आहे आणि अजूनही काही क्लायंटसोबत ऐतिहासिक कारणांसाठी करतो. काय म्हणता येईल? Patroni बॉक्सच्या बाहेर ऑटोफायलरसह येते, Repmgr एक अतिरिक्त वैशिष्ट्य म्हणून ऑटोफायलरसह येते जे सक्षम करणे आवश्यक आहे. आम्हाला प्रत्येक नोडवर Repmgr डिमन चालवावे लागेल आणि नंतर आम्ही ऑटोफायलर कॉन्फिगर करू शकतो.

Repmgr पोस्टग्रेस नोड्स जिवंत आहेत का ते तपासते. Repmgr प्रक्रिया एकमेकांचे अस्तित्व तपासतात, हा फारसा कार्यक्षम दृष्टिकोन नाही. नेटवर्क अलगावची गुंतागुंतीची प्रकरणे असू शकतात ज्यात एक मोठा Repmgr क्लस्टर अनेक लहानांमध्ये विभक्त होऊ शकतो आणि कार्य करणे सुरू ठेवू शकतो. मी बर्याच काळापासून Repmgr चे अनुसरण करत नाही, कदाचित ते निश्चित केले असेल ... किंवा कदाचित नाही. परंतु DCS मधील क्लस्टरच्या स्थितीबद्दल माहिती काढून टाकणे, जसे स्टोलॉन, पॅट्रोनी करतात, हा सर्वात व्यवहार्य पर्याय आहे.

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

मी ते मोठ्याने सांगितले नाही, परंतु कोरम पूर्ण होण्यासाठी DCS क्लस्टर देखील फेलओव्हर असणे आवश्यक आहे, म्हणजे नोड्सची विषम संख्या आहे. DCS क्लस्टर अनुपलब्ध झाल्यास, किंवा कोरम पूर्ण होऊ शकला नाही, म्हणजे काही प्रकारचे नेटवर्क स्प्लिट किंवा नोड निकामी झाल्यास काय होईल? या प्रकरणात, Patroni क्लस्टर केवळ वाचनीय मोडमध्ये जातो. Patroni क्लस्टर क्लस्टरची स्थिती आणि काय करावे हे ठरवू शकत नाही. ते DCS शी संपर्क साधू शकत नाही आणि तेथे नवीन क्लस्टर स्थिती संचयित करू शकत नाही, त्यामुळे संपूर्ण क्लस्टर केवळ वाचनात जातो. आणि ऑपरेटरच्या मॅन्युअल हस्तक्षेपाची किंवा DCS पुनर्प्राप्त होण्याची प्रतीक्षा करते.

ढोबळपणे बोलायचे तर, डीसीएस ही सेवा आपल्यासाठी बेसइतकीच महत्त्वाची बनते?

होय होय. बर्‍याच आधुनिक कंपन्यांमध्ये, सर्व्हिस डिस्कव्हरी हा पायाभूत सुविधांचा अविभाज्य भाग आहे. पायाभूत सुविधांमध्ये डेटाबेस असण्यापूर्वीच त्याची अंमलबजावणी केली जात आहे. तुलनेने बोलायचे झाल्यास, पायाभूत सुविधा लाँच केल्या गेल्या, DC मध्ये तैनात केल्या गेल्या आणि आमच्याकडे लगेच सर्व्हिस डिस्कव्हरी आहे. जर ते कॉन्सुल असेल तर त्यावर DNS बांधता येईल. जर हे Etcd असेल, तर कुबर्नेट्स क्लस्टरचा एक भाग असू शकतो, ज्यामध्ये इतर सर्व काही तैनात केले जाईल. मला असे वाटते की सर्व्हिस डिस्कव्हरी हा आधीपासूनच आधुनिक पायाभूत सुविधांचा अविभाज्य भाग आहे. आणि ते डेटाबेसपेक्षा त्याबद्दल खूप आधी विचार करतात.

धन्यवाद!

स्त्रोत: www.habr.com