शारीरिक रूप से विविध स्थानों में स्वचालित विफलता के साथ अत्यधिक उपलब्ध MySQL के लिए वास्तुकला


19

मैं डेटा केंद्रों के बीच MySQL के लिए उच्च उपलब्धता (HA) समाधानों पर शोध कर रहा हूं।

एक ही भौतिक वातावरण में स्थित सर्वरों के लिए, मैंने सक्रिय निष्क्रिय दृष्टिकोण का उपयोग करते हुए दिल की धड़कन (अस्थायी वीआईपी) के साथ दोहरे मास्टर को प्राथमिकता दी है। दिल की धड़कन एक सीरियल कनेक्शन के साथ-साथ ईथरनेट कनेक्शन दोनों पर है।

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

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

इस परिदृश्य के साथ, भौतिक लिंक (धारावाहिक) की कमी के कारण विभाजित मस्तिष्क की अधिक संभावना है। यदि WAN दोनों साइटों के बीच नीचे चला जाता है, तो VIP दोनों साइटों पर समाप्त हो जाएगा, जहां विभिन्न प्रकार के अप्रिय परिदृश्य desync का परिचय दे सकते हैं।

एक और संभावित मुद्दा जो मैं देख रहा हूं वह है कि भविष्य में इस बुनियादी ढांचे को तीसरे डेटा सेंटर तक पहुंचाने में कठिनाई हो रही है।

नेटवर्क लेयर फोकस नहीं है। इस स्तर पर वास्तुकला लचीली है। फिर से, मेरा ध्यान डेटा अखंडता और साथ ही MySQL डेटाबेस के साथ स्वचालित विफलता को बनाए रखने के लिए एक समाधान है। मैं इस के आसपास बाकी डिजाइन की संभावना है।

क्या आप दो शारीरिक रूप से विविध साइटों के बीच MySQL हा के लिए एक सिद्ध समाधान सुझा सकते हैं?

इसे पढ़ने के लिए समय निकालने के लिए शुक्रिया। मैं आपकी सिफारिशों को पढ़ने के लिए उत्सुक हूं।


1
हाय - क्या आपने अभी तक एक दृष्टिकोण निर्धारित किया है? यह सुनना दिलचस्प होगा कि आपने क्या करने का फैसला किया है। हमें भी वही तकलीफ़ है।
मार्टिन

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

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

मैंने जो उत्तर यहां दिया है, उसमें कुछ अतिरिक्त जानकारी शामिल है: serverfault.com/questions/142683/… अंतिम उत्पादन कार्यान्वयन होने पर मैं फॉलो-अप भी प्रदान करूंगा।
वार्नर

जवाबों:


9

आप "CAP" प्रमेय समस्या का सामना करेंगे। आपके पास एक ही समय में संगतता, उपलब्धता और विभाजन-सहिष्णुता नहीं हो सकती है।

DRBD / MySQL HA ब्लॉक डिवाइस स्तर पर तुल्यकालिक प्रतिकृति पर निर्भर करता है। यह ठीक है जबकि दोनों नोड्स उपलब्ध हैं, या यदि कोई अस्थायी गलती से ग्रस्त है, रिबूट किया गया है आदि, तो वापस आता है। नेटवर्क विभाजन मिलते ही समस्याएं शुरू हो जाती हैं।

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

जब आपकी मशीनें एक ही स्थान पर होती हैं, तो आप इस समस्या को प्राप्त करने के लिए संचार का एक माध्यमिक चैनल (आमतौर पर एक सीरियल केबल, या क्रॉसओवर ईथरनेट) जोड़ सकते हैं - इसलिए माध्यमिक को पता है कि प्राथमिक कब सामान्य है, और यह नेटवर्क विभाजन नहीं है ।


अगली समस्या प्रदर्शन की है। जब DRBD सभ्य ** प्रदर्शन दे सकता है, जब आपकी मशीनों में कम-विलंबता कनेक्शन होता है (उदाहरण गीगाबिट ईथरनेट - लेकिन कुछ लोग समर्पित उच्च गति नेटवर्क का उपयोग करते हैं), नेटवर्क में जितनी अधिक विलंबता होती है, उतने लंबे समय तक लेन-देन करने में लगता है *** । ऐसा इसलिए है क्योंकि यह लिखने के स्थायित्व को सुनिश्चित करने के लिए एप्लिकेशन को "ओके" कहने से पहले सभी राइट्स को स्वीकार करने के लिए द्वितीयक सर्वर (जब यह ऑनलाइन है) के लिए इंतजार करना होगा।

यदि आप अलग-अलग डाटासेंटर में ऐसा करते हैं, तो आपके पास आमतौर पर कई मिलीसेकंड विलंबता होती है, भले ही वे पास हों।

** एक सभ्य स्थानीय IO नियंत्रक की तुलना में अभी भी बहुत धीमी है

*** आप एक उच्च उपलब्धता DRBD सिस्टम के लिए MyISAM का उपयोग नहीं कर सकते हैं क्योंकि यह अशुद्ध शटडाउन से ठीक से / स्वचालित रूप से पुनर्प्राप्त नहीं करता है, जो एक विफलता के दौरान आवश्यक है।


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

1
वास्तव में। डेटा एक ही बार में दो जगह नहीं होना चाहता।
मैट सिमंस

3

दो सर्वरों (या अधिक) डेटा केंद्रों को एक साथ जोड़ने के लिए एक वीएलएएन का उपयोग करने के बारे में क्या। फिर आप स्वचालित विफलता के लिए CARP का उपयोग कर सकते हैं। सब कुछ सिंक में रखने के लिए डेटाबेस प्रतिकृति का उपयोग करें।

यदि आप डेटा केंद्र के मालिक हैं, तो आप यह सुनिश्चित कर सकते हैं कि प्रत्येक डेटा केंद्र में कई WAN अपलिंक हों।


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

3

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

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

विंडोज सर्वर 2008 मल्टी-साइट क्लस्टरिंग

स्पष्ट रूप से सटीक तकनीक लिनक्स डोमेन पर मैप नहीं करती है, लेकिन अवधारणाएं समान हैं।


1

क्षमा करें, यह अभी तक एक और नेटवर्क है, लेकिन नीचे सड़क के लिए एक विचार ...

आपके द्वारा उल्लेखित विभाजित मस्तिष्क परिदृश्य के लिए, आपके पास दो साइटों के बीच निरर्थक लिंक हो सकते हैं और साथ ही ऐसा होने की संभावना को कम कर सकते हैं।


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

0

ध्यान दें कि आप शायद BGP का उपयोग नहीं कर सकते हैं, क्योंकि सबसे छोटा नियमित ब्लॉक 4k, a / 22 है, सौभाग्य एक हो रहा है। संभवतः DNS आधारित समाधान की आवश्यकता है।


वास्तविकता की एक खुराक के लिए +1। आप अल्ट्राडएनएस और इसकी साइट निगरानी सेवा "साइटबैकर" जैसी अच्छी तरह से प्रबंधित डीएनएस सेवा का उपयोग कर सकते हैं ताकि आपको वहां सबसे ज्यादा मिल सके।
मार्टिन

1
हमारे पास पहले से ही बीजीपी है। यह मेरे सवाल के दायरे से बाहर है।
वार्नर

2
नहीं, सबसे छोटा नियमित ब्लॉक / 24 है। वास्तव में, नहीं .. सबसे छोटा शारीरिक रूप से अक्षम्य ब्लॉक / 28 है, लेकिन आपको सभी द्वारा अनदेखा किए जाने की संभावना है। सबसे छोटा उपसर्ग जो सुनने को मिलेगा / 24 है।
टॉम ओ'कॉनर

0

आपके पास मौजूद डेटा की मात्रा के आधार पर एक सही उत्तर देना कठिन हो सकता है, आदि में आप जिस सर्वर पर इसे फिट करना चाहते हैं, वह कहा जा रहा है, मेरा उत्तर एक नहीं हो सकता है, या कम से कम वह है जिसे आप खोज रहे हैं।

MySQL के साथ कई साइट के लिए कोई सिद्ध समाधान नहीं है। लेकिन समाधान है कि काम करता है। जैसा कि कुछ ने कहा, हाँ DRDB ठीक काम करता है, लेकिन इसकी सीमा या संभव मुद्दा आपके सेटअप के आधार पर है।

क्या आपको कभी भी एक तीसरी साइट (अन्य डेटासेन्ट) की आवश्यकता होगी? यदि हां, तो आपको यह करने के लिए कितना समय और पैसा देना होगा?

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

डेटासेंटर्स को ध्यान में रखते हुए अक्सर नीचे नहीं जाते हैं, कई साइट का मतलब है लोड बैलेंसिंग और कुछ डीएनएस हैकिंग, क्या यह उसी डेटासेंटर में होने वाला है? यदि हां, तो एक डेटासेंटर जो भी कारण से आप इस मुद्दे पर चलेगा क्योंकि आपके डीएनएस और लोडबैलेंसिंग का एक अच्छा हिस्सा इस डेटासेंटर में होने वाला है।

तो आपको योजना बनानी पड़ सकती है कि मस्तिष्क की स्थिति को विभाजित करें। प्रत्येक संभावित सेटअप को अलग करने के लिए, थूक मस्तिष्क की स्थिति को हल करने का तरीका अलग है। इसके अलावा, प्रत्येक समाधान में एक्स राशि का समय लगता है।
शुरुआत से 3 डेटासेंटर का उपयोग करने की योजना बनाना कहीं अधिक आसान हो सकता है। मैं कोई MySQL विशेषज्ञ नहीं हूं, लेकिन मैंने सुना है कि यदि आप कभी भी मुद्दे पर चलते हैं तो उत्पादन में 2 से 3 मास्टर्स होना आसान था।

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

सौभाग्य!


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

0

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

यदि आपको MySQL के लिए वास्तव में HA समाधान की आवश्यकता है, तो आपको MySQL क्लस्टर के साथ जाना होगा क्योंकि DRBD आपको विफलताओं के मामले में डेटा अखंडता नहीं दे सकता है।



0

एक सीरियल केबल की कमी पर काबू पाना वास्तव में बहुत आसान है, आप अंधेरे युग से एक चीज का उपयोग करते हैं जिसे मॉडेम कहा जाता है - आपके पास प्रत्येक छोर पर एक है और फिर पीपीपी लिंक पर हार्टबीट चलाएं। आप फ्रेम रिले का उपयोग भी कर सकते हैं। दोनों विधियां आपके पास लेयर 1/2 निरर्थक रास्तों से संबंधित किसी भी चिंता को ठीक कर देंगी।

हालाँकि यह कहा जा रहा है - DRBD किसी भी लिंक पर लगभग 300 (s (नोट thats 0.3ms) से अधिक के साथ चल रहा है विलंबता बहुत जल्दी हास्यास्पद हो जाता है।

आप बेहतर MySQL प्रतिकृति का उपयोग करके बेहतर कार्य करेंगे, और असफल ओवरों को करने के लिए PPP & eth से अधिक LinuxHA।

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


दिलचस्प विचार। मैं पहले एक Ptp पर विफलता के रूप में डायल-अप का उपयोग किया है। हालांकि मुझे नहीं लगता कि यह सीएपी प्रमेय मुद्दे को पूरी तरह से समाप्त कर देगा, मेरा मानना ​​है कि यह विभाजित मस्तिष्क को कम होने की पूरक हो सकता है। कई फुट प्रत्यक्ष शारीरिक संबंध द्वारा बनाए गए आत्मविश्वास के समान स्तर बनाना मुश्किल है।
वार्नर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.