अपडेट: अप्रैल २०१8
प्रश्न के समय यह उत्तर सही था, लेकिन तब से चीजें आगे बढ़ी हैं। संस्करण 3.4 के बाद से समानता शुरू की गई है, और मैंने जिस टिकट का संदर्भ दिया है, वह मूल रूप से बंद हो गया है। अधिक जानकारी के लिए मैं इस अधिक हाल के उत्तर में कुछ विवरणों को शामिल करता हूं । मैं शेष उत्तर को छोड़ दूंगा क्योंकि यह सामान्य मुद्दों / बाधाओं के साथ-साथ पुराने संस्करण पर किसी के लिए भी मान्य है।
मूल उत्तर
यदि आप रुचि रखते हैं तो मैं M202 उन्नत पाठ्यक्रम में एक चंक प्रवास के साथ क्या होता है, इसका पूरा विवरण देता हूं । सामान्य शब्दों में, मान लें कि माइग्रेशन बहुत तेज़ नहीं होते हैं, यहाँ तक कि खाली विखंडू के लिए भी, क्योंकि हाउसकीपिंग को एक सक्रिय प्रणाली में माइग्रेशन सुनिश्चित करने के लिए किया जाता है (ये अभी भी होते हैं, भले ही संतुलन कुछ भी हो रहा हो)।
इसके अतिरिक्त, पूरे क्लस्टर पर एक समय में केवल एक ही प्रवास हो रहा है - कोई समानता नहीं है। तो, इस तथ्य के बावजूद कि आपके पास दो "पूर्ण" नोड्स और दो "खाली" नोड्स हैं, किसी भी समय सबसे अधिक माइग्रेशन हो रहा है (सबसे अधिक विखंडू के साथ शार्क और सबसे कम के साथ शार्क)। इसलिए, 2 शर्ड जोड़े जाने से आपको संतुलन की गति के मामले में कुछ भी हासिल नहीं होता है और बस चांस की संख्या बढ़ जाती है जिसे स्थानांतरित करना पड़ता है।
माइग्रेशन के लिए, चंक्स की संभावना ~ 30MiB आकार में होती है (यह इस बात पर निर्भर करता है कि आपने डेटा को कैसे पॉप्युलेट किया है, लेकिन आम तौर पर यह डिफ़ॉल्ट अधिकतम चंक साइज़ के साथ आपका औसत होगा)। आप db.collection.getShardDistribution()उस जानकारी में से कुछ के लिए दौड़ सकते हैं , और अपने विखंडू के बारे में और अधिक जानकारी प्राप्त करने के तरीकों के लिए यहां मेरा जवाब देख सकते हैं।
चूंकि कोई अन्य गतिविधि नहीं चल रही है, इसलिए लक्ष्य शारद होने के लिए एक माइग्रेशन के लिए (नए जोड़े गए शार्प्स में से एक) स्रोत शार्क (मूल 2 में से एक) से 30MiB डेटा पढ़ना और कॉन्फिग सर्वर को अपडेट करना होगा एक बार यह करने के बाद नए स्थान को प्रतिबिंबित करें। 30MiB डेटा को लोड किए बिना एक सामान्य सिस्टम के लिए बहुत अधिक अड़चन नहीं होनी चाहिए।
यदि यह धीमा है, तो कई संभावित कारण हैं कि मामला क्यों है, लेकिन व्यस्त न होने वाली प्रणाली के लिए सबसे आम हैं:
- सोर्स डिस्क I / O - यदि डेटा को पढ़ने पर सक्रिय मेमोरी में नहीं है, तो उसे डिस्क से पृष्ठांकित किया जाना चाहिए
- नेटवर्क - अगर लेटेंसी, रेट लिमिटिंग, पैकेट लॉस आदि है तो रीड में काफी समय लग सकता है
- लक्ष्य डिस्क I / O - डेटा और इंडेक्स को डिस्क पर लिखा जाना है, बहुत सारे इंडेक्स इसे बदतर बना सकते हैं, लेकिन आमतौर पर यह एक हल्के लोड सिस्टम पर कोई समस्या नहीं है
- गर्भपात और असफल प्रवासन के कारण पलायन की समस्याएँ (कॉन्फ़िगरेशन सर्वर के साथ समस्याएँ, प्राइमरी पर हटाए गए मुद्दे)
- प्रतिकृति अंतराल - प्रतिकृति सेटों के लिए पलायन के लिए, चिंता लिखें
w:2या w:majorityडिफ़ॉल्ट रूप से उपयोग किया जाता है और इसे संतुष्ट करने के लिए दूसरी तिथि तक की आवश्यकता होती है।
यदि सिस्टम व्यस्त था, तो स्मृति विवाद, ताला विवाद आमतौर पर यहां भी संदिग्ध होंगे।
माइग्रेशन कितना समय ले रहे हैं, इसके बारे में अधिक जानकारी प्राप्त करने के लिए, यदि वे असफल हो रहे हैं आदि, तो अपने में प्रविष्टियों पर एक नज़र डालें config.changelog:
// connect to mongos
use config
db.changelog.find()
जैसा कि आपने देखा है, और जैसा कि मैं आमतौर पर लोगों को बताता हूं कि जब मैं प्रशिक्षण / शिक्षा करता हूं, अगर आपको पता है कि आपको 4 शार्क की आवश्यकता होगी, तो आमतौर पर रैंप अप के बजाय 4 से शुरू करना बेहतर होता है। यदि आप करते हैं, तो आपको इस बात से अवगत होना चाहिए कि एक शार्क को जोड़ने में एक लंबा समय लग सकता है, और शुरू में एक लाभ के बजाय संसाधनों पर शुद्ध नकारात्मक है ( उस के अधिक विस्तृत चर्चा के लिए मेरी शार्किंग श्रृंखला के भाग II देखें )।
अंत में, ट्रैक माइग्रेशन / सुधार / टिप्पणी के लिए अनुरोध पर चंक पलायन की समानता को सुधारने के लिए, SER-4355 देखें