भौगोलिक रूप से अलग सर्वरों पर MySQL प्रतिकृति

Question

मेरा संगठन यह देख रहा है कि भौगोलिक रूप से हमारे सर्वरों को कैसे फैलाया जाए जबकि बैकअप बहुत अद्यतित रखा जाए, और आदर्श रूप से लोड को फैलाया जाए।

प्रारंभिक बात जो मेरे मन में है, वह है MySQL पर रेल्स। लेखन दर बहुत अधिक नहीं है (लेख / टिप्पणियां 1 प्रति मिनट से भी कम समय में छोड़ी जा रही हैं, हालांकि कुछ में बड़ी मीडिया संलग्नक हैं)।

इसलिए,

• MySQL प्रतिकृति व्यापक क्षेत्र नेटवर्क में अच्छी तरह से काम करती है?
• क्या कनेक्शन (या एक दास सर्वर) नीचे जाने का मतलब है कि मैनुअल हस्तक्षेप की आवश्यकता है (एक बार दो सर्वर एक-दूसरे से बात कर सकते हैं) या स्वचालित पुनर्प्राप्ति है?
• यदि गुरु गायब हो जाता है, तो दास को गुरु में बदलने की क्या आवश्यकता है? वहाँ मानक स्क्रिप्ट / उपकरण है कि प्रबंधन में मदद करने के लिए कर रहे हैं?
• कोई अन्य gotchas आदि?

Answer 1

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

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

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

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

Answer 2

MySQL 5.1 में प्रतिकृति नाटकीय रूप से बदल गई। 5.0 में केवल स्टेटमेंट आधारित प्रतिकृति का उपयोग किया गया था। अब आपके पास पंक्ति आधारित प्रतिकृति या मिश्रित आधारित प्रतिकृति करने का विकल्प है। यह बहुत प्रभावित करेगा कि आप WAN पर कैसे दोहराते हैं।

यदि आपके पास या तो करने की क्षमता है: ए) क्या आईपी लेती है (यदि आपके सर्वर भौगोलिक रूप से अलग हैं तो यह संभावना नहीं है) बी) चुस्त डीएनएस परिवर्तन करें आप मास्टर्स बदलने के लिए ऐप कोड / कॉन्फ़िगरेशन को संशोधित करने से बच सकते हैं। हम शॉर्ट कैशिंग और नकली .internal डोमेन के साथ आंतरिक DNS का उपयोग करते हैं। अगर हमें कुछ अन्य सर्वर होने के लिए मास्टरडब.इन को बदलने की आवश्यकता है, तो 5 सेकंड में परिवर्तन प्रस्तावित होता है।

एक एकल डेटा केंद्र के भीतर हम IP ले ओवर का उपयोग करते हैं। DB के सभी सर्वरों में वर्चुअल इंटरफेस (eth0: 1, eth0: 2, eth0: 3) होते हैं, जो बूट पर ifup'ed नहीं होते हैं। यदि दासों में से एक को संभालने की जरूरत है, तो आप बस ifup eth0: 2 और यह मास्टर है। इस परिदृश्य में, eth0 'if' है जिसका उपयोग हम शेल और ऐसे में करते हैं। ऐप eth0: 1 से कनेक्ट होते हैं, जो बूट पर सक्रिय नहीं होगा यदि मेरी स्क्रिप्ट पता लगाती है कि आईपी लिया गया है। (विकिपीडिया STONITH) अन्य इफ़्स मास्टर्स के आईपी को लेने के लिए हैं जिन्हें विफल करने की आवश्यकता हो सकती है।

Answer 3

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