RabbitMQ क्लस्टर नेटवर्क विफलता

Question

के बाद पुन: कनेक्ट नहीं कर रहा है मैं उत्पादन में दो नोड्स के साथ RabbitMQ क्लस्टर और क्लस्टर ये त्रुटि संदेश के साथ टूट रहा है:

= त्रुटि रिपोर्ट ==== 23 दिसम्बर 2011 :: 04:21:34 ===
** नोड खरगोश @ rabbitmq02 जवाब नहीं **
** निकाला जा रहा है (टाइम आउट) कनेक्शन **

= जानकारी की रिपोर्ट ==== 23 दिसम्बर -2011 :: 04 : 21: 35 ===
नोड खरगोश @ rabbitmq02 खो गया 'खरगोश'

= त्रुटि रिपोर्ट ==== 23-दिसंबर -2011 :: 04: 21: 49 ===
मेनेसिया (खरगोश @ rabbitmq01): ** त्रुटि ** mnesia_event मिला {inconsistent_database, running_partitioned_network, खरगोश @ rabbitmq02}

मैं "tcpkill" का उपयोग कर दो नोड्स के बीच संबंध की हत्या करके समस्या अनुकरण करने की कोशिश की, क्लस्टर काट दिया गया है, और आश्चर्यजनक रूप से दो नोड्स पुन: कनेक्ट करने का प्रयास नहीं कर रहे हैं!

जब क्लस्टर टूट जाता है, तो हैपरॉक्स लोड बैलेंसर अभी भी दोनों नोड्स को सक्रिय के रूप में चिह्नित करता है और दोनों को अनुरोध भेजता है, हालांकि वे क्लस्टर में नहीं हैं।

मेरे सवालों का:

1. नोड्स एक क्लस्टर के रूप में काम करने के लिए कॉन्फ़िगर कर रहे हैं, जब मैं एक नेटवर्क विफलता मिलता है, इसलिए वे के बाद फिर से कनेक्ट करने का प्रयास नहीं कर रहे हैं?

2. मैं टूटी हुई क्लस्टर की पहचान कैसे कर सकता हूं और नोड्स को बंद कर सकता हूं? दो नोड्स के साथ अलग-अलग काम करते समय मेरे पास स्थिरता समस्याएं होती हैं।

Answer 1

इस तरह की विफलता से ठीक होने का एक और तरीका मैनेशिया के साथ काम करना है जो डेटाबेस है कि खरगोश एमक्यू दृढ़ता तंत्र के रूप में उपयोग करता है और खरगोश एमक्यू उदाहरणों (और मास्टर/गुलाम स्थिति) के सिंक्रनाइज़ेशन के लिए इसका नियंत्रण होता है । सभी विवरण के लिए, निम्न URL देखें: http://www.erlang.org/doc/apps/mnesia/Mnesia_chap7.html

यहाँ प्रासंगिक अनुभाग जोड़ना:

कई अवसरों हैं जब Mnesia पता लगा सकता है कि नेटवर्क एक संचार विफलता की वजह से विभाजित किया गया है।

एक ऐसा होता है जब मेनेसिया पहले से चल रहा है और चल रहा है और एरलांग नोड फिर से संपर्क करते हैं। फिर मैनेशिया अन्य नोड पर मैनेशिया से संपर्क करने का प्रयास करेगा, यह देखने के लिए कि क्या यह भी सोचता है कि नेटवर्क को थोड़ी देर के लिए विभाजित किया गया है। यदि दोनों नोड्स पर मैनेशिया ने मैनेशिया_डाउन प्रविष्टियों को एक दूसरे से लॉग किया है, तो मैनेशिया {inconsistent_database, running_partitioned_network, नोड} नामक एक सिस्टम इवेंट उत्पन्न करता है जो मैनेशिया के ईवेंट हैंडलर और अन्य संभावित ग्राहकों को भेजा गया है। डिफ़ॉल्ट ईवेंट हैंडलर त्रुटि लॉगजर में त्रुटि की रिपोर्ट करता है।

एक अन्य अवसर जब मैनेशिया का पता लगा सकता है कि नेटवर्क संचार विफलता के कारण विभाजित है, स्टार्ट-अप पर है। यदि मैनेशिया पता लगाता है कि स्थानीय नोड और अन्य नोड दोनों को एक दूसरे से mnesia_down प्राप्त हुआ है, तो यह एक {inconsistent_database, start_partitioned_network, नोड} सिस्टम ईवेंट उत्पन्न करता है और ऊपर वर्णित के रूप में कार्य करता है।

आवेदन पता लगाता है कि वहाँ एक संचार विफलता जो एक असंगत डेटाबेस का कारण हो सकता है, यह समारोह mnesia उपयोग कर सकते हैं कर दिया गया है: जो नोड्स एक तालिका लोड किया जा सकता है से इंगित करने के लिए set_master_nodes (टैब, नोड्स)।

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

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

कार्यों mnesia: system_info (master_node_tables) और mnesia: table_info (टैब, master_nodes) संभावित मास्टर नोड्स के बारे में जानकारी प्राप्त करने के लिए इस्तेमाल किया जा सकता है।

निर्धारण जो डेटा संचार विफलता के बाद रखने के लिए बाहर Mnesia की गुंजाइश है। एक दृष्टिकोण यह निर्धारित करना होगा कि कौन सा "द्वीप" नोड्स का बहुमत है। {बहुमत, सच} महत्वपूर्ण तालिकाओं के लिए विकल्प का उपयोग सुनिश्चित करना है कि नोड्स है कि एक "बहुमत द्वीप" का हिस्सा नहीं हैं उन तालिकाओं को अद्यतन करने में सक्षम नहीं हैं का एक तरीका हो सकता है। ध्यान दें कि यह अल्पसंख्यक नोड्स पर सेवा में कमी का गठन करता है। यह उच्च स्थिरता गारंटी के पक्ष में एक ट्रेडऑफ होगा।

फ़ंक्शन मैनेशिया: force_load_table (टैब) का उपयोग टेबल लोड करने के लिए किया जा सकता है, भले ही तालिका लोड तंत्र सक्रिय हो।

यह ऐसी असफलताओं से उबरने का एक और अधिक लंबा और शामिल तरीका है .. लेकिन बेहतर स्पष्टता और डेटा पर नियंत्रण है कि अंतिम मास्टर नोड में उपलब्ध होना चाहिए दे देंगे (इस डेटा हानि की मात्रा को कम कर सकते हैं कि हो सकता है जब खरगोश एमक्यू मास्टर्स "विलय" हो)। ठहराव अल्पसंख्यक मोड और autoheal मोड:

Answer 2

खरगोश एमक्यू क्लस्टर अविश्वसनीय नेटवर्क (खरगोश एमक्यू दस्तावेज़ीकरण का हिस्सा) पर अच्छी तरह से काम नहीं करते हैं। तो जब नेटवर्क विफलता होती है (दो नोड क्लस्टर में) प्रत्येक नोड सोचता है कि यह क्लस्टर में मास्टर और एकमात्र नोड है। दो मास्टर नोड्स स्वचालित रूप से पुनः कनेक्ट नहीं होते हैं, क्योंकि उनके राज्य स्वचालित रूप से सिंक्रनाइज़ नहीं होते हैं (यहां तक ​​कि एक खरगोश एमक्यू दास के मामले में भी - वास्तविक संदेश सिंक्रनाइज़ेशन नहीं होता है - दास सिर्फ "पकड़ता है" जैसे संदेश कतार से और अधिक संदेश से खपत होते हैं जोड़ा गया)।

rabbitmqctl cluster_status 

नोड्स क्लस्टर का भाग में से प्रत्येक पर

:

आप एक टूटी हुई क्लस्टर कि क्या आदेश का पता लगाने के लिए, चलाते हैं। अगर क्लस्टर टूटा हुआ है तो आप केवल एक नोड देखेंगे। कुछ की तरह:

Cluster status of node rabbit@rabbitmq1 ... 
[{nodes,[{disc,[rabbit@rabbitmq1]}]},{running_nodes,[rabbit@rabbitmq1]}] 
...done. 

ऐसे मामलों में, आप नोड्स है कि मूल क्लस्टर का हिस्सा बना (इतना है कि यह अन्य गुरु नोड मिलती है (कहना rabbitmq1) में से एक पर आदेशों के निम्नलिखित सेट चलाने की आवश्यकता होगी एक दास के रूप में क्लस्टर) में:

rabbitmqctl stop_app 

rabbitmqctl reset 

rabbitmqctl join_cluster rabbit@rabbitmq1 

rabbitmqctl start_app 

अंत में फिर से क्लस्टर की स्थिति की जांच .. इस बार तुम दोनों नोड्स देखना चाहिए।

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

Answer 3

RabbitMQ भी अपने आप नेटवर्क विभाजन से निपटने के लिए दो तरीके प्रदान करता है। (डिफ़ॉल्ट व्यवहार को अनदेखा मोड के रूप में जाना जाता है)।

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

autoheal मोड RabbitMQ में स्वचालित रूप से एक विभाजन हुआ है समझा जाता है, तो एक जीत विभाजन पर तय करेगा। यह उन सभी नोड्स को पुनरारंभ करेगा जो विजेता विभाजन में नहीं हैं। और अगर है कि अभी भी एक ड्रॉ तो पैदा करता विभाजन से एक है, जीतने विभाजन एक जो सबसे स्वचालित रूप से निपटने के विभाजन

ग्राहकों जुड़े (है या अगर यह एक ड्रॉ, सबसे नोड्स के साथ एक उत्पादन होता है एक अनिर्दिष्ट तरीके से चुना गया)।

आप या तो pause_minority या autoheal करने के लिए अपने विन्यास फाइल में खरगोश आवेदन के लिए विन्यास पैरामीटर cluster_partition_handling की स्थापना करके या तो मोड सक्षम कर सकते हैं।

कौन सा मोड मैं चुनना चाहिए?

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

इसके साथ ही कहा, आपको इस प्रकार वसूली मोड लेने के लिए इच्छा हो सकती है:

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

• pause_minority आपका नेटवर्क शायद कम विश्वसनीय है। आपने ईसी 2 में 3 एजेड में क्लस्टर किया है, और आप मानते हैं कि केवल एक एजेड एक बार में विफल हो जाएगा। उस परिदृश्य में आप शेष दो एजेड काम करना जारी रखना चाहते हैं और असफल एजेड से नोड्स स्वचालित रूप से फिर से जुड़ने के लिए और जब एजेड वापस आते हैं तो बिना किसी झगड़े के।

• ऑटोहेल आपका नेटवर्क विश्वसनीय नहीं हो सकता है। आप डेटा अखंडता की तुलना में सेवा की निरंतरता से अधिक चिंतित हैं। आपके पास दो नोड क्लस्टर हो सकते हैं।

यह उत्तर rabbitmq दस्तावेज़ों से ref है। https://www.rabbitmq.com/partitions.html आपको एक और विस्तृत विवरण देगा।