क्या एक ही भौतिक सर्वर पर प्रतिकृति चलाना नासमझी है?


13

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

हमारे मौजूदा डेटाबेस सर्वर काफी कम उपयोग के रूप में दूर के रूप में cpu (लोड औसत वास्तव में एक क्वाड-कोर पर 1 से ऊपर कभी नहीं मिलता है)। इसलिए अग्रणी विचार कुछ नई ड्राइव में टॉस करना है और मेमोरी को 8GB (16 से) तक दोगुना करना है और उसी भौतिक मशीन पर दूसरा mysql इंस्टेंस चलाना है। प्रत्येक उदाहरण में डेटाबेस के लिए अलग डिस्क होगी।

क्या इस विचार में कुछ गलत है?

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

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

जवाबों:


11

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

उपयोग अधिकार कारणों से उपयोगकर्ताओं को विशुद्ध रूप से अलग करने के लिए, एक अच्छा RDBMS ऐसा करने के अधिक प्रभावी तरीके प्रदान करेगा।

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

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


1
मेरा विचार था कि गुलाम myIsam पर टेबल के ताले के साथ प्रतिस्पर्धा नहीं करेगा जब मास्टर को (जटिल रिपोर्टों के लिए) लिखा जा रहा हो।
डेरेक डाउनी

@Dest: यह निश्चित रूप से एक संभावित बोनस होगा, हाँ (+1)। अन्य तालिका प्रकारों के लिए भी जब एक बड़े लॉक (जैसे टेबल लॉक) को जटिल रिपोर्ट क्वेरी द्वारा अनुरोध किया जा सकता है। मैं अपने उत्तर में एक नोट जोड़ दूंगा ताकि अधिक टिप्पणियां आने पर कट फॉर्म प्रदर्शन की संभावना कम हो।
डेविड स्पिललेट

7

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

इसके लिए एक बोधगम्य उपयोग उपयोगकर्ताओं को किसी भी तरह अलग करना होगा, लेकिन फिर, मैंने सोचा होगा कि इसके साथ किया जा सकता है GRANT


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

2

यह वास्तव में नासमझ माना जाता है, क्या आप अधिक कोर का लाभ लेने की कोशिश कर रहे हैं? नए डिजाइन के लक्ष्य क्या हैं?

(एक जवाब के रूप में पोस्ट किया गया कि टिप्पणी को ध्यान में रखते हुए कोई टिप्पणी नहीं दी गई)


ड्राइव विफलता के खिलाफ थोड़ी सी सुरक्षा प्रदान करें, और साथ ही जटिल रिपोर्ट के लिए एक सर्वर प्रदान करें जो मास्टर तक पहुंचने वाले उत्पादन साइटों को धीमा नहीं करेगा।
डेरेक डाउनी

क्या वे एक ही डिस्क नियंत्रक का उपयोग करेंगे या क्या आप नए स्पिंडल के अलावा एक नया डिस्क नियंत्रक स्थापित कर पाएंगे?
jcolebrand

1
मैं अभी इस एक के पार आया। मैंने कई बयानों का लाभ उठाते हुए आपके बयानबाजी के सवालों पर गौर किया। मैंने वास्तव में चर्चा की कि मेरे जवाब में दो महीने बाद आपने यह कहा। आपकी जानकारी के आगे +1 मेरी। BTW यहाँ कई बार MySQL चलाने पर एक अच्छा वीडियो है: youtu.be/5uKBg9prA1A
RolandoMySQLDBA

BTW मेरे नियोक्ता का एक क्लाइंट है, जिसके लिए मैंने इस आर्किटेक्चर की व्यवस्था की है। इसमें एक मशीन पर तीन पढ़े गए दास हैं (सभी MyISAM में) जबकि मास्टर सभी InnoDB है।
RolandoMySQLDBA 3

1

यह एक दोधारी तलवार हो सकती है

आप mysql के कई उदाहरणों को मास्टर के समान सर्वर पर केवल पढ़ने के लिए दास के रूप में चला सकते हैं, बशर्ते कि MySQL का प्रत्येक उदाहरण एक अलग डिस्क पर रहता हो। यह केवल वांछनीय है यदि आप MySQL के पुराने संस्करण चला रहे हैं जो कई कोर (सीपीयू) का लाभ नहीं लेते हैं। MySQL के नवीनतम संस्करणों को वास्तव में कई सीपीयू का उपयोग करने के लिए ट्यून किया जा सकता है, जो MySQL के कई उदाहरणों को चलाकर कई कोर तक पहुंचने के लिए अनावश्यक बनाता है।

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


0

मैं एक अलग सर्वर यानी B पर B और B के गुलाम A पर प्रतिकृति को पार करूँगा। हम अपने सर्वर पर कई उदाहरण चलाते हैं और कोई समस्या नहीं है क्योंकि हमारे MySQL सर्वर क्षमता पर नहीं थे। एक रनिंग सर्वर पर विफल बैकअप से रिस्टोर करने की तुलना में बहुत तेज है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.