आपका मास्टर समानांतर में निष्पादित करता है और अपने दास धारावाहिक में निष्पादित करता है। यदि आपका मास्टर 1 वास्तविक घंटे में 1.5 घंटे के आवेषण/अपडेट/निष्पादन को संसाधित कर सकता है, तो आपका दास पीछे गिर जाएगा।
यदि आप अपने दास पर लिखने के प्रदर्शन में सुधार करने के तरीकों को नहीं ढूंढ पा रहे हैं (अधिक मेमोरी, तेज डिस्क, अनावश्यक अनुक्रमणिका हटा दें), तो आपने अपने अनुप्रयोग आर्किटेक्चर में एक सीमा को मारा है। आखिरकार आप एक बिंदु पर हिट करेंगे कि आप यथासंभव वास्तविक समय में परिवर्तन निष्पादित नहीं कर सकते क्योंकि आपका मास्टर समानांतर में निष्पादित कर सकता है।
बहुत सी बड़ी साइटें अपने डेटाबेस को खराब करती हैं: अपने मास्टर + गुलाम को एकाधिक मास्टर + गुलाम क्लस्टर में विभाजित करने पर विचार करें। फिर इन क्लस्टर में अपने ग्राहक आधार को विभाजित करें। जब एक गुलाम पीछे गिरना शुरू करता है, तो यह एक और क्लस्टर जोड़ने का समय है।
यह सस्ता नहीं है, लेकिन जब तक आप समानांतर में बिनलॉग प्रतिकृति निष्पादित बयानों को बनाने का कोई तरीका नहीं ढूंढ पाते हैं, तो शायद आपको इसे करने का बेहतर तरीका नहीं मिलेगा।
अपडेट (2017): MySQL अब parallel slave worker threads का समर्थन करता है। अभी भी कई चर हैं जो गुलाम को पीछे गिरने का कारण बनेंगे, लेकिन गुलामों को धारावाहिक क्रम में लिखने की आवश्यकता नहीं है। समानांतर दास धागे के प्रतिबद्ध आदेश को संरक्षित करना चुनना एक महत्वपूर्ण विकल्प है कि किसी भी समय दास की सटीक स्थिति महत्वपूर्ण है या नहीं।
स्रोत
2008-11-07 19:59:31
mysql प्रतिकृति विकल्पों की तुलना में एक स्थिर, तेज़ और पतला समाधान है। booking.com अविश्वसनीय रूप से कई mysql उदाहरणों और कैस्केड प्रतिकृति सेटअप का उपयोग करता है जो मैंने सुना है। यदि आपकी वेबसाइट वास्तव में बहुत बड़ी है, तो आपको समस्या निवारण के साथ आपकी मदद करने के लिए एक पेशेवर की आवश्यकता हो सकती है, यदि आपका दास बहुत छोटा हार्डवेयर-वार नहीं है। मैं व्यक्तिगत रूप से प्रति सेकंड 10k + प्रश्नों के साथ सेटअप करता हूं जिसमें गुलाम अंतराल के साथ कोई समस्या नहीं है। संभवतः आपकी प्रतिकृति सेटिंग्स भी सही नहीं हैं। – sjas