2TB संग्रह को शार्ड करने और 24 घंटे के अंदर अपने सभी शार्ड में डेटा वितरित करने की आवश्यकता है? अपने डेटा माइग्रेशन में तेजी लाने के लिए रीशेयरिंग का लाभ उठाएं! अस्वीकरण: मैं एक मोंगोडीबी कर्मचारी हूं, लेकिन व्यक्त की गई सभी राय और विचार मेरे अपने हैं इस पोस्ट में, हम "रीशर्ड-टू-शार्ड" नामक एक तकनीक को कवर करेंगे, जो आपके क्लस्टर में शार्क में डेटा को तेज़ी से फैलाने के लिए रीशर्डिंग का उपयोग करती है। हम आगे बढ़ेंगे: माइग्रेशन से पहले और उसके दौरान विचार. तेज़ डेटा माइग्रेशन कैसे आरंभ करें, मॉनिटर करें और निरस्त करें। यदि आप शार्डिंग के लिए नए हैं या क्षैतिज मापनीयता कैसे प्रदान करता है, इस पर एक पुनश्चर्या चाहते हैं, तो कृपया देखें . MongoDB मोंगोडीबी मैनुअल विषयसूची पृष्ठभूमि रीशर्ड-टू-शर्ड के क्या फायदे हैं? मुझे रीशर्ड-टू-शर्ड का उपयोग कब करना चाहिए? मुझे रीशर्ड-टू-शर्ड का उपयोग कब नहीं करना चाहिए? Reshard-to-shard पूर्वापेक्षाएँ क्या हैं? रीशर्ड-टू-शार्ड तकनीक अवलोकन रीशर्ड-टू-शार्ड उदाहरण पूछे जाने वाले प्रश्न पृष्ठभूमि जब एक संग्रह को शुरू में मल्टी-शर्ड क्लस्टर पर शार्प किया जाता है, तो बैलेंसर उस शार्ड से डेटा माइग्रेट करना शुरू कर देता है, जो हाल ही में शार्ड किए गए संग्रह को क्लस्टर में अन्य शार्ड्स में समान रूप से संग्रह को वितरित करता है। जब बैलेंसर डेटा माइग्रेट कर रहा होता है, तो एक समय में एक शार्ड केवल एक माइग्रेशन में भाग ले सकता है, चाहे कितने संग्रहों को माइग्रेट करने की आवश्यकता हो। इसका मतलब है कि 3-शार्क क्लस्टर में, एक समय में केवल दो शार्ड उनके बीच डेटा स्थानांतरित कर सकते हैं। आंतरिक निष्पादन अंतरों के कारण पुनः साझा करना समान सीमाएं साझा नहीं करता है। क्योंकि रीशार्डिंग सभी डेटा को फिर से लिख रहा है, यह क्लस्टर में सभी शार्ड्स के समानांतर डेटा लिखने में सक्षम है, थ्रूपुट को बढ़ाता है और बैलेंसर क्या हासिल कर सकता है, इसके सापेक्ष शार्ड्स में डेटा माइग्रेट करने के समय को बहुत कम कर देता है। आपके मौजूदा संग्रह को उपयोग करने के लिए आपके मौजूदा संग्रह को उपलब्ध रखते हुए, प्रत्येक शार्ड पर पृष्ठभूमि में एक नई शार्ड कुंजी के साथ रीशार्डिंग एक नया संग्रह बनाता है। एक बार जब सभी दस्तावेजों को नए संग्रह में क्लोन कर दिया जाता है, तो कटओवर होता है। पुरानी शार्क कुंजी के साथ मौजूदा संग्रह को पुनः साझा करने के संचालन द्वारा बनाए गए नए संग्रह के पक्ष में छोड़ दिया गया है। रीशर्ड-टू-शर्ड के क्या फायदे हैं? सबसे पहले, यह बहुत तेज है! रीशर्डिंग का लाभ उठाकर, एक ग्राहक 22.5 घंटों में अपने 3.5TB संग्रह को 4 शार्क में विभाजित और वितरित करने में सक्षम था। यदि बैलेंसर की चंक माइग्रेशन की डिफ़ॉल्ट विधि को छोड़ दिया जाए तो इसी प्रक्रिया में 30 दिन लगेंगे। दूसरा, यह आपके वर्कलोड को कम से कम प्रभावित करता है! बैलेंसर द्वारा डेटा माइग्रेट करने के बाद, इसे क्लीन-अप ऑपरेशन कहा जाता है डेटा दान करने वाले शार्ड पर केवल एक शार्ड के रूप में प्रत्येक विशिष्ट दस्तावेज़ का स्वामी हो सकता है। रेंज विलोपन एक I/O-गहन ऑपरेशन है जो आपके क्लस्टर के प्रदर्शन को प्रभावित कर सकता है। रीशार्डिंग को रेंज हटाने की आवश्यकता नहीं है क्योंकि यह पुराने संग्रह की एक बूंद को नए शार्ड कुंजी के साथ नए संग्रह में कटौती करने के बाद आयोजित करता है। श्रेणी विलोपन तीसरा, आप स्वचालित रूप से अपने डिस्क स्थान को पुनः प्राप्त करते हैं! पुराने संग्रह को हटाकर, यह किसी भी संग्रह द्वारा उपयोग किए जाने वाले संग्रहण स्थान को बिना किसी ऑपरेशन को निष्पादित किए बिना मुक्त कर देता है . इसका मतलब यह है कि यदि आप चाहें तो ऑपरेशन के बाद स्टोरेज को अधिक तेज़ी से और आसानी से कम कर सकते हैं। कॉम्पैक्ट उदाहरण के लिए, एक ग्राहक अपने सबसे बड़े संग्रह का पुनः साझा करने का कार्य पूरा होने से पहले shard0 पर लगभग 2.8TB का उपभोग कर रहा था। जब पुनः साझा करना समाप्त हो गया, तो 1.9 टीबी संग्रहण स्थान तुरंत लौटा दिया गया! वे 2.7TB संग्रहण से 873GB संग्रहण तक चले गए। मुझे रीशर्ड-टू-शर्ड का उपयोग कब करना चाहिए? जब आप प्रारंभ में किसी भी आकार के संग्रह को किसी भी संख्या में शार्क में विभाजित कर रहे हों। उत्तर: ऐसे कुछ परिदृश्य हैं जहां संतुलन तेज हो सकता है (उदाहरण के लिए 100 जीबी से कम), लेकिन आपको अभी भी या इसलिए, यदि आपके पास क्षमता है, तो हम अनुशंसा करते हैं कि आप जिस संग्रह को शार्ड करना चाहते हैं, वह कितना भी बड़ा हो, फिर से शार्ड-टू-शार्ड करें। कॉम्पैक्ट प्रारंभिक सिंक के माध्यम से भंडारण को हटाने और भंडारण को पुनः प्राप्त करने पर ध्यान देना होगा। मुझे रीशर्ड-टू-शर्ड का उपयोग कब नहीं करना चाहिए? आपको रीशर्ड-टू-शार्ड रणनीति का उपयोग तब नहीं करना चाहिए जब: आपका एप्लिकेशन दो सेकंड के लिए राइट्स की रुकावट को बर्दाश्त नहीं कर सकता है ताकि रीशर्ड किए गए संग्रह में कटओवर की अनुमति मिल सके। संग्रह को डिफ़ॉल्ट रूप से दो सेकंड के लिए फिर से साझा करने के लिए लिखने की अवधि को अवरुद्ध किया जा सकता है, एक कॉन्फ़िगर करने योग्य पैरामीटर है जो रुकावट की अवधि को संशोधित कर सकता है। आपका संग्रह एक समय-श्रृंखला संग्रह है यदि आप समय-श्रृंखला संग्रह को पुनः साझा करने का प्रयास करते हैं, तो आपको एक त्रुटि संदेश प्राप्त होगा जो बताता है कि समय-श्रृंखला संग्रह को पुनः साझा करना समर्थित नहीं है। ऊपर सूचीबद्ध परिदृश्यों के लिए, संग्रह को शार्प करने और बैलेंसर को डेटा माइग्रेट करने देने की पारंपरिक विधि का उपयोग करें। Reshard-to-shard पूर्वापेक्षाएँ क्या हैं? एक क्लस्टर जो MongoDB 5.0 या उच्चतर चला रहा है MongoDB आपको अपने संग्रह के लिए उपयुक्त शार्ड कुंजी का चयन करना होगा। अस्थायी शार्द कुंजी और वांछित शार्द कुंजी दोनों का समर्थन करने के लिए आवश्यक अनुक्रमणिका बनाएँ। इसके अतिरिक्त, चूंकि आप डेटा माइग्रेशन गति को तेज करने के लिए रीशार्डिंग का उपयोग कर रहे हैं, कृपया स्वयं को इससे परिचित कराएं . आवश्यकताओं और सीमाओं को पुनः साझा करना रीशर्डिंग ऑपरेशन को सफलतापूर्वक निष्पादित करने के लिए आपके क्लस्टर में होना चाहिए: प्रत्येक शार्ड पर उपलब्ध संग्रह आकार प्रति शार्ड 1.2x। उदाहरण के लिए, यदि आप 4 शार्क में 1TB संग्रह को शार्ड कर रहे हैं, तो 4 शार्क में वितरित किए जाने पर शार्प किए गए संग्रह का आकार 250GB प्रति शार्ड होता है। आप चाहते हैं कि प्रत्येक शार्ड पर कम से कम 300 जीबी स्टोरेज उपलब्ध हो। आई/ओ क्षमता 50% से कम CPU उपयोग 80% से कम एटलस का उपयोग करने वाले ग्राहक जिनका क्लस्टर स्टोरेज, आई/ओ और सीपीयू आवश्यकताओं को पूरा नहीं करता है, रीशर्डिंग को निष्पादित करने के लिए आसानी से अस्थायी रूप से कर सकते हैं और/या एक सफल रीशर्डिंग ऑपरेशन के लिए अनुमति देने के लिए अपने क्लस्टर के संसाधनों को बढ़ाने के लिए। ऑपरेशन पूरा होने के बाद वे सामान्य हो सकते हैं। उनके क्लस्टर को स्केल करें भंडारण को अनुकूलित करें रीशर्ड-टू-शार्ड तकनीक अवलोकन रीशर्ड-टू-शर्ड ऑपरेशन को अंजाम देने के लिए दो बहुत ही सरल चरण हैं: एक अस्थायी शार्ड कुंजी में शार्ड अपनी वांछित शार्क कुंजी में पुनः लोड करें मैं पहले एक अस्थायी शार्ड की में शार्ड क्यों लगाऊंगा, और क्या यह मेरे आवेदन को नुकसान नहीं पहुंचाएगा? चलो समझाते हैं! चरण एक: एक अस्थायी ठीकरा कुंजी के साथ ठीकरा वर्तमान में, पुनः साझा करना उसी शार्ड कुंजी में पुनः साझा करने का समर्थन नहीं करता है (यह "नो-ऑप" के रूप में सफल होगा क्योंकि आप पहले से वांछित स्थिति में हैं)। इस सीमा से बचने के लिए, रीशर्ड-टू-शार्ड तकनीक को जानबूझकर एक अस्थायी शार्प की में शार्डिंग की आवश्यकता होती है जो कि वांछित शार्ड की से अलग होती है। रेंज शार्डिंग और हैश्ड शार्डिंग दोनों के लिए MongoDB के समर्थन के कारण अस्थायी शार्ड कुंजी को आपके संग्रह के लिए आपके द्वारा चुनी गई वांछित शार्ड कुंजी से बहुत संशोधित किया जा सकता है। थोड़ा अस्थायी शार्क कुंजी को आपके केवल एक शार्क कुंजी फ़ील्ड के लिए एक अलग विभाजन रणनीति का चयन करना चाहिए। कुछ प्रश्नों जैसे कि अपडेटऑन (), अपडेटमैनी (), डिलीटऑन (), आदि के लिए सीमाओं के कारण, जिसमें शार्ड कुंजी को शामिल करने के लिए क्वेरी की आवश्यकता होती है, आप एक अलग विभाजन रणनीति का उपयोग करेंगे। MongoDB विभाजन रणनीतियों का उपयोग यह निर्धारित करने के तरीके के रूप में करता है कि आपके डेटा को आपके क्लस्टर में शार्क में कैसे वितरित किया जाए और यह दस्तावेज़ में मानों को नहीं बदलता है। इसका अर्थ यह है कि आपका एप्लिकेशन या किसी अन्य क्वेरी का उपयोग कर सकता है जिसके लिए दोनों विभाजन रणनीतियों के साथ शार्क कुंजी की आवश्यकता होती है। केवल updateOne उदाहरण के लिए, यदि आपके द्वारा अपने संग्रह के लिए चुनी गई वांछित शार्ड कुंजी है: {"_id": "hashed"} प्रारंभिक रूप से आपके संग्रह के लिए उपयोग की जाने वाली अस्थायी शार्क कुंजी होनी चाहिए: {"_id": 1} कंपाउंड शार्क कुंजियों के लिए, आपके केवल एक शार्क कुंजी फ़ील्ड को एक अलग विभाजन रणनीति का उपयोग करने की आवश्यकता होती है। उदाहरण के लिए, यदि आपके द्वारा अपने संग्रह के लिए चुनी गई वांछित शार्ड कुंजी है: { launch_vehicle: 1, payload: 1} आपकी अस्थायी ठीकरा कुंजी होनी चाहिए: { launch_vehicle: 1, payload: "hashed"} रीशर्ड-टू-शार्ड रणनीति शार्ड कुंजी में तत्काल रीशार्डिंग के लिए कॉल करती है जिसका उपयोग आप अस्थायी शार्ड कुंजी के साथ संग्रह के प्रारंभिक शार्डिंग के बाद लंबी अवधि के लिए करेंगे। यह 99% से अधिक डेटा को एक शार्ड पर रखता है, जबकि रीशर्डिंग ऑपरेशन निष्पादित होता है, जो प्रसारण प्रश्नों के प्रभाव को बहुत कम करता है। यदि आप यह सुनिश्चित करना चाहते हैं कि आपका 100% डेटा एक शार्ड पर है, तो आप संग्रह को शुरू में अस्थायी शार्ड कुंजी के साथ शार्प करने से पहले बैलेंसर को बंद कर सकते हैं। बैलेंसर को अक्षम करने से गारंटी मिलती है कि रीशेयरिंग शुरू होने से पहले कोई माइग्रेशन नहीं होगा। हम नीचे दिए गए उदाहरण में बताएंगे कि आप बैलेंसर को कैसे बंद कर सकते हैं। चूंकि आपने अपनी अस्थायी और वांछित शार्ड कुंजी के लिए दोनों इंडेक्स बनाए होंगे, जबकि रीशर्डिंग ऑपरेशन आयोजित किया जा रहा है, आपकी वांछित शार्ड कुंजी का उपयोग करने वाले प्रश्न प्रदर्शनकारी होंगे क्योंकि वे वांछित शार्ड कुंजी के लिए इंडेक्स का लाभ उठा सकते हैं, जबकि आपका संग्रह अस्थायी रूप से विभाजित है आपकी अस्थायी शार्क कुंजी द्वारा। चरण दो: अपनी वांछित शार्ड कुंजी में पुनः आकार दें दूसरा चरण एक सामान्य रीशार्डिंग ऑपरेशन निष्पादित कर रहा है सिवाय इसके कि आप रीशार्डिंग कैसे आपके लाभ के लिए काम करता है, इसके साइड इफेक्ट का लाभ उठा रहे हैं। पुनः साझा करने के चार प्रमुख चरण हैं: - रीशर्डिंग से गुजरने वाले संग्रह का नमूना लिया जाता है और नई शार्क कुंजी के आधार पर डेटा का एक नया वितरण निर्धारित किया जाता है। इनिशियलाइज़ेशन - रीशर्डिंग ऑपरेशन नई शार्क कुंजी के आधार पर सभी शार्क पर एक नया खाली अस्थायी शार्ल्ड संग्रह बनाता है और मौजूदा संग्रह का समर्थन करने वाले गैर-शार्क कुंजी इंडेक्स सहित इंडेक्स बनाता है। इंडेक्स - दस्तावेज़ों को नई शार्ड कुंजी के अनुसार शार्ड्स पर क्लोन किया जाता है, और दस्तावेज़ों में किसी भी संशोधन को रीशर्डिंग ऑपरेशन निष्पादित करते समय लागू किया जाता है। क्लोन, कैच-अप, और अप्लाई - अस्थायी संग्रह का नाम बदल दिया गया है और संग्रह को फिर से व्यवस्थित करने की जगह ले ली गई है और अब पुराना संग्रह हटा दिया गया है। प्रतिबद्ध ऊपर दिए गए चरणों की समीक्षा करने के बाद, आप देख सकते हैं कि आप तेज़ डेटा मूवमेंट का लाभ कैसे प्राप्त करेंगे, एक शार्डेड संग्रह जो ऑपरेशन पूरा होने के बाद आपके शार्ड्स में समान रूप से वितरित किया जाता है, और एक ही बार में स्टोरेज स्पेस खाली कर देता है। एक बार रीशार्डिंग ऑपरेशन पूरा हो जाने के बाद, आप क्लीन-अप ऑपरेशन कर सकते हैं जैसे कि अस्थायी शार्ड की इंडेक्स को गिराना और अपनी स्थिर-स्थिति की जरूरतों को पूरा करने के लिए अपने क्लस्टर और/या अपने स्टोरेज को कम करना। रीशर्ड-टू-शार्ड उदाहरण मान लें कि आप एक ऐसे एप्लिकेशन पर काम कर रहे हैं जो वाणिज्यिक विमानों को ट्रैक करेगा ताकि ग्राहकों को सूचित किया जा सके कि उनकी उड़ान में देरी होने की संभावना है। आपने अपने एप्लिकेशन के क्वेरी पैटर्न का अध्ययन किया है और समीक्षा की है कि कौन सी विशेषताएँ एक अच्छी शार्क कुंजी में योगदान करती हैं। आपके द्वारा अपने संग्रह के लिए चुनी गई शार्ड कुंजी है: { airline: 1, flight_number: 1, date: "hashed" } शार्ड कुंजी निर्धारित करने के साथ, आप रीशर्ड-टू-शार्ड ऑपरेशन को निष्पादित करने के लिए पूर्वापेक्षाओं की जांच शुरू कर सकते हैं। सबसे पहले, आप अपनी अस्थायी शार्क कुंजी उत्पन्न करते हैं। जैसा कि पहले कहा गया है, आप चाहते हैं कि आपकी अस्थायी शार्क कुंजी वांछित शार्ड कुंजी का थोड़ा संशोधित संस्करण हो। तो आपके द्वारा चुनी गई अस्थायी शार्ड कुंजी है: { airline: 1, flight_number: 1, date: 1} अगला, आप अस्थायी और अंतिम शार्ड कुंजियों का समर्थन करने के लिए अनुक्रमणिका बनाते हैं। कमांड के माध्यम से Mongo शेल का उपयोग करके इंडेक्स बनाए जा सकते हैं: db.collection.createIndexes() db.flight_tracker.createIndexes([ {"airline": 1, "flight_number": 1, date: "hashed"}, {"airline": 1, "flight_number": 1, date: 1} ]) निम्नलिखित कमांड के माध्यम से मोंगो शेल का उपयोग करके इंडेक्स बिल्ड की निगरानी की जा सकती है: db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] }) यदि आप यह सुनिश्चित करना चाहते हैं कि आपके संग्रह को शार्डिंग करने के बीच कोई माइग्रेशन न हो और जब रीशर्डिंग लागू हो, तो आप निम्न कमांड चलाकर बैलेंसर को बंद कर सकते हैं: sh.stopBalancer() यदि आपका मोंगोडीबी क्लस्टर एटलस पर तैनात है, तो आप एटलस यूआई का उपयोग आसानी से उपलब्ध मेट्रिक्स की समीक्षा करने के लिए कर सकते हैं जो आपको सूचित करते हैं कि आपके क्लस्टर में पर्याप्त मुफ्त स्टोरेज उपलब्ध है और साथ ही सीपीयू और आई/ओ हेडरूम एक रीशर्डिंग ऑपरेशन करने के लिए है। यदि पर्याप्त संग्रहण स्थान उपलब्ध नहीं है या I/O हेडरूम है, तो आप संग्रहण को स्केल कर सकते हैं। सीपीयू हेडरूम की कमी के लिए आप क्लस्टर को स्केल कर सकते हैं। स्टोरेज और क्लस्टर दोनों को स्केल करना एटलस यूआई के माध्यम से आसानी से किया जाता है। क्लस्टर कॉन्फ़िगरेशन तक पहुँचना सरल है और इसे आपके समूह की ओवरव्यू स्क्रीन से किया जा सकता है जो समूह के लिए तैनात सभी क्लस्टर प्रदर्शित करता है। सभी पूर्वापेक्षाओं को पूरा करने के बाद, आप रीशर्ड-टू-शार्ड प्रक्रिया के पहले भाग को शुरू कर सकते हैं - संग्रह को अस्थायी शार्ड कुंजी के साथ शार्ड करना। फिर आप संग्रह को ठीक करने के लिए Mongo शेल और sh.shardCollection() कमांड का उपयोग कर सकते हैं: sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: 1} ) sh.shardCollection() पूर्ण होने पर एक दस्तावेज़ लौटाएगा, ऑपरेशन सफल होने पर फ़ील्ड ठीक 1 का मान होगा। { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) } एक बार जब संग्रह शार्ड हो जाता है, तो आप तुरंत संग्रह को पुनः साझा करने के लिए आगे बढ़ सकते हैं! मोंगो शेल में अपने संग्रह को वांछित शार्क कुंजी उपयोग sh.reshardCollection() में पुनः लोड करने के लिए: sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" }) यदि आप मोंगो शेल में sh.status() कमांड चलाते हैं, तो आपको आउटपुट में एक नया संग्रह दिखाई देगा, जिसमें नए संग्रह के नाम का प्रारूप होगा। यह वह संग्रह है जिसे पुनः साझा करना आपकी इच्छित शार्ड कुंजी के अनुसार डेटा का निर्माण और वितरण कर रहा है <db_name>.system.resharding.<UUID> flight_tracker संग्रह के लिए रीशार्डिंग ऑपरेशन की स्थिति की निगरानी के लिए आप निम्न आदेश का उपयोग कर सकते हैं db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "main.flight_tracker" } } ]) कमांड का आउटपुट आपको सूचित करेगा कि वर्तमान में रीशर्डिंग ऑपरेशन किस चरण में चल रहा है और शेषऑपरेशनटाइमएस्टिमेटेडसेक फ़ील्ड के माध्यम से पूरा होने का अनुमानित समय है। कृपया ध्यान दें कि पूरा होने के लिए पुनः साझाकरण अनुमानित समय निराशावादी है और पुनः साझा करने की कार्रवाइयाँ रिपोर्ट किए जाने की तुलना में काफ़ी कम समय लेती हैं! जब प्रत्येक शार्ड का डेटा आकार क्लस्टर में शार्ड्स की संख्या से विभाजित किए जा रहे संग्रह के आकार से बढ़ जाता है, तो रीशर्डिंग ऑपरेशन पूरा होने वाला होना चाहिए। उदाहरण के लिए एक 1TB संग्रह को 4 शार्ड्स में रीशेयर किया जा रहा है, जब प्रत्येक शार्ड में 250GB लिखा हो, तो रीशर्डिंग ऑपरेशन पूरा हो जाना चाहिए (शेर्ड पर अन्य डेटा डालने, अपडेट करने या हटाने के लिए लेखांकन नहीं)। यदि आपका क्लस्टर एटलस पर तैनात है, तो आप क्लस्टर के मेट्रिक्स टैब का उपयोग करके एटलस यूआई के माध्यम से रीशार्डिंग ऑपरेशन की प्रगति की निगरानी भी कर सकते हैं। मोंगोडीबी 6.0 और अधिक से अधिक चलने वाले एटलस क्लस्टर के लिए - आप शार्क डेटा आकार प्रदर्शन विकल्प का उपयोग कर सकते हैं और फिर के सिंटैक्स के साथ एक संग्रह का चयन कर सकते हैं। यह दृश्य अस्थायी संग्रह को अलग करता है और केवल नए संग्रह के डेटा आकार में वृद्धि प्रदर्शित करेगा। <db_name>.system.resharding.<UUID> मोंगोडीबी 5.0 चलाने वाले एटलस क्लस्टर के लिए - आप डीबी लॉजिकल डेटा साइज डिस्प्ले विकल्प का उपयोग कर सकते हैं। यह दृश्य संग्रह-स्तर के अलगाव की अनुमति नहीं देता है। जबकि रीशार्डिंग निष्पादित हो रही है, क्लस्टर से तीन मेट्रिक्स की आपको मुख्य रूप से निगरानी करनी चाहिए: उपलब्ध संग्रहण - सभी उपलब्ध संग्रहण का उपभोग करने से क्लस्टर अस्थिरता हो सकती है सीपीयू उपयोगिता - उच्च सीपीयू उपयोग से खराब क्लस्टर प्रदर्शन हो सकता है I/O उपयोग - आपकी क्षमता से अधिक I/O उपयोग से क्लस्टर प्रदर्शन में गिरावट आ सकती है यदि आप अपने क्लस्टर को नकारात्मक रूप से प्रभावित करने के बारे में चिंतित हैं, तो आप निम्न आदेश के माध्यम से प्रक्रिया के प्रतिबद्ध हिस्से तक पहुंचने से पहले रीशर्डिंग ऑपरेशन को तुरंत रोक सकते हैं: कभी भी sh.abortReshardCollection("main.flight_tracker") यदि आपने यह सुनिश्चित करने के लिए बैलेंसर को बंद कर दिया है कि संग्रह को शार्डिंग और रीशर्ड करने के बीच कोई माइग्रेशन नहीं होता है, तो निम्न आदेश का उपयोग करके बैलेंसर को वापस चालू करें: sh.startBalancer() रीशार्डिंग ऑपरेशन जब यह समाप्त हो जाता है तो ऑपरेशन सफल रहा या नहीं, इनवोकिंग क्लाइंट को वापस आ जाएगा। चूंकि रीशर्डिंग एक लंबे समय तक चलने वाला ऑपरेशन है और आपने मोंगो शेल सत्र को बंद कर दिया हो सकता है, आप जांच कर सकते हैं कि क्या शार्डिंग ऑपरेशन अभी भी रीशर्डिंग मॉनिटरिंग एकत्रीकरण का उपयोग करके निष्पादित हो रहा है यदि आप विवरण चाहते हैं या यह देखने के लिए कि आउटपुट में अस्थायी संग्रह अभी भी मौजूद है या नहीं। यदि रीशार्डिंग एग्रीगेशन कुछ भी वापस नहीं करता है या यदि आपको sh.status() के आउटपुट में कोई अस्थायी संग्रह नहीं दिखता है, तो रीशर्डिंग ऑपरेशन समाप्त हो गया है। ऑपरेशन सफल रहा या नहीं यह पता लगाने के लिए आप का उपयोग कर सकते हैं: श स्थिति () db.collection.getShardDistribution db.flight_tracker.getShardDistribution() यदि रीशर्डिंग सफलतापूर्वक पूर्ण हो जाती है तो आपको एक आउटपुट देखना चाहिए जहां वितरण शार्क के बराबर है। MongoDB 6.0 और अधिक समता डेटा आकार प्रति शार्ड द्वारा निर्धारित की जाती है, इसलिए आपको db.collection.getShardDistribution के आउटपुट में प्रत्येक शार्ड पर लगभग समान मात्रा में डेटा देखना चाहिए। MongoDB 5.0 के लिए समता प्रति शार्ड की संख्या से निर्धारित होती है, इसलिए आपको db.collection.getShardDistribution के आउटपुट में प्रत्येक शार्ड पर समान संख्या में चंक्स देखने चाहिए। यदि आपका क्लस्टर एटलस पर तैनात किया गया है, तो आप यह निर्धारित करने के लिए मेट्रिक्स टैब के माध्यम से एटलस यूआई का उपयोग कर सकते हैं कि रीशर्डिंग ऑपरेशन सफल है या नहीं। मोंगोडीबी 6.0 और अधिक से अधिक चलने वाले एटलस क्लस्टर के लिए - आप शार्क डेटा आकार प्रदर्शन विकल्प का उपयोग कर सकते हैं और फिर अपने संग्रह का चयन कर सकते हैं जो पुनः साझा कर रहा है। आपको प्रदर्शित प्रति शार्ड के बराबर डेटा देखना चाहिए। मोंगोडीबी 5.0 चलाने वाले एटलस क्लस्टर के लिए - आप चंक्स डिस्प्ले विकल्प का उपयोग कर सकते हैं और फिर अपने संग्रह का चयन कर सकते हैं जो रीशर्डिंग से गुजरता है। आपको अपने क्लस्टर में सभी शार्क में लगभग समान संख्या में भाग दिखाई देने चाहिए। शार्ड डेटा आकार और टुकड़ों की संख्या दोनों के लिए एटलस यूआई के संग्रह नाम प्रारूप का उपयोग करके अस्थायी रूप से इसका नाम बदलने से पहले और पुराने को छोड़ने के कारण प्रासंगिक मीट्रिक में तेज वृद्धि प्रदर्शित करेगा। पुरानी ठीकरा कुंजी के साथ संग्रह। <db_name>.system.resharding.<UUID> यदि रीशार्डिंग निरस्त कर दी जाती है, तो का आउटपुट संभवतः उस शार्ड पर अधिकांश डेटा दिखाएगा जिस पर संग्रह को शुरू में शार्ल्ड किया गया था। रीशर्डिंग के साथ गर्भपात दुर्लभ हैं और इसकी संभावना है क्योंकि रीशार्डिंग 2 सेकंड या उससे कम समय में संग्रह कटओवर नहीं कर सका। db.collection.getShardDistribution यदि ऐसा है, तो हम अनुशंसा करते हैं कि पुनःशेयरिंग प्रारंभ करने का समय निर्धारित किया जाए ताकि यह आपके क्लस्टर के लिए कम ट्रैफ़िक की अवधि के दौरान प्रतिबद्ध होने का प्रयास करे। वैकल्पिक रूप से, यदि आपका एप्लिकेशन 2 सेकंड से अधिक के लिए लिखने की रुकावट को सहन कर सकता है, तो आप 2000ms डिफ़ॉल्ट से परे resharingCriticalSectionTimeoutMillis पैरामीटर के साथ अवधि बढ़ाकर प्रतिबद्ध समय को संशोधित कर सकते हैं। एक बार रीशर्डिंग ऑपरेशन पूरा हो जाने के बाद आप क्लीन-अप ऑपरेशन कर सकते हैं जैसे कि अस्थायी शार्ड की इंडेक्स को गिराना और अपनी स्थिर-स्थिति की जरूरतों को पूरा करने के लिए अपने क्लस्टर और/या अपने स्टोरेज को स्केल करना। अब आप मोंगो शेल में कमांड के साथ अस्थायी इंडेक्स को छोड़ सकते हैं! db.collection.dropIndex() db.flight_tracker.dropIndex( {"airline": 1, "flight_number": 1, "date": 1} ) पूछे जाने वाले प्रश्न Reshard-to-shard में कितना समय लगता है? यह आपके संग्रह के आकार, आपके संग्रह के लिए इंडेक्स की संख्या और आकार और आपके क्लस्टर में शार्क की संख्या पर निर्भर करता है, लेकिन हमें विश्वास है कि आप 4TB संग्रह को 48 में 4 शार्क में 10 इंडेक्स के साथ रीशर्ड-टू-शार्ड कर सकते हैं। घंटे या उससे कम। बैलेंसर को माइग्रेशन को संभालने देने में 30 दिन या उससे अधिक का समय लगेगा। बैलेंसर को डेटा माइग्रेट करने देने की तुलना में रीशेयरिंग तेजी से क्यों होती है? बैलेंसर और रीशेयरिंग डेटा माइग्रेट करने के तरीके अलग-अलग हैं। चंक माइग्रेशन की तुलना में रीशार्डिंग दस्तावेजों को एक अलग क्रम में पढ़ता है और चूंकि रीशेयरिंग पुराने संग्रह की एक बूंद के साथ समाप्त होती है इसलिए डिस्क स्थान को जारी करने के लिए श्रेणी हटाने की कोई प्रतीक्षा नहीं है। मैं एक ऐसे संग्रह पर रीशर्ड-टू-शार्ड का उपयोग करना चाहता हूं जिसमें विशिष्टता बाधा है और हैश इंडेक्स अद्वितीयता को लागू करने का समर्थन नहीं करते हैं। यदि आपके संग्रह में अद्वितीयता बाधा है तो आप रीशर्ड-टू-शार्ड का उपयोग कर सकते हैं, लेकिन आपको एक अलग दृष्टिकोण अपनाना होगा। विभाजन रणनीति को बदलने के बजाय अपनी अस्थायी शार्ड कुंजी में एक अतिरिक्त फ़ील्ड जोड़कर आप अपनी वांछित शार्ड कुंजी में पुनः लोड करने की क्षमता को अनलॉक करते हैं। उदाहरण के लिए यदि आपकी वांछित शार्क कुंजी है: { launch_vehicle: 1, payload: 1} आपकी अस्थायी ठीकरा कुंजी होगी: { launch_vehicle: 1, payload: 1, launch_pad: 1} कृपया प्रश्नों के लिए सीमाओं से अवगत रहें (उदा: अपडेटऑन (), अपडेटमैनी (), डिलीटऑन ()) जिसके लिए क्वेरी को शार्क कुंजी शामिल करने की आवश्यकता होती है। आपके एप्लिकेशन में उन सभी परिदृश्यों में अस्थायी शार्ड कुंजी शामिल जहां एक क्वेरी को पुनः शार्डिंग ऑपरेशन पूर्ण होने तक सफलतापूर्वक निष्पादित करने के लिए शार्ड कुंजी की आवश्यकता होती है। होनी चाहिए मैं चल रहे रीशेयरिंग ऑपरेशन की निगरानी कैसे करूं? निम्नलिखित आदेश चलाएँ: db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ]) मैं चल रहे रीशेयरिंग ऑपरेशन को कैसे रोकूं? निम्नलिखित कमांड चलाएँ, जो तुरंत रीशेयरिंग ऑपरेशन को रद्द कर देता है: sh.abortReshardCollection("<database>.<collection>") मैं अपने क्लस्टर प्रदर्शन को प्रभावित करने के बारे में चिंतित हूं। यदि आप पहले उल्लिखित रीशार्डिंग आवश्यकताओं को पूरा करते हैं, तो ऑपरेशन को आपके क्लस्टर प्रदर्शन को प्रभावित नहीं करना चाहिए। हालाँकि, यदि आपका क्लस्टर एटलस पर तैनात है, तो आप अपने क्लस्टर को अस्थायी रूप से स्केल-टू-शार्ड ऑपरेशन निष्पादित करते समय स्केल कर सकते हैं और ऑपरेशन पूरा होने के बाद क्लस्टर को वापस स्केल कर सकते हैं। जब रीशेयरिंग ऑपरेशन निष्पादित हो रहा हो तो मुझे अपने क्लस्टर के कौन से मेट्रिक्स की निगरानी करनी चाहिए? संग्रहण स्थान उपलब्ध - यदि आपके किसी भी शार्ड में 100GB से कम संग्रहण उपलब्ध है, तो आपको फिर से आकार देना बंद कर देना चाहिए CPU उपयोग - यदि आपका क्लस्टर सभी उपलब्ध कंप्यूट संसाधनों का उपभोग कर रहा है, तो आप संसाधन विवाद का कारण बन सकते हैं और आपको पुनः लोड करना बंद कर देना चाहिए I/O खपत - यदि आपका क्लस्टर सभी उपलब्ध IOPS का उपभोग कर रहा है, तो आप संसाधन संबंधी विवाद का कारण बन सकते हैं और आपको पुनः साझा करना बंद कर देना चाहिए। ऐसा प्रतीत होता है कि अस्थायी संग्रह मेरे सभी शार्क में समान रूप से वितरित है, फिर से साझा करना पूर्ण क्यों नहीं है? अपनी वांछित शार्क कुंजी के साथ संग्रह में कटौती करने से पहले, इसे अवश्य करना चाहिए रीशेयरिंग शुरू होने के बाद से हुए सभी लेखनों के साथ। यदि आपका लिखने का कार्यभार भारी है तो कैच-अप चरण को समाप्त होने में अधिक समय लग सकता है। पकड़ो मेरा आवेदन 1 सेकंड से अधिक के लिए अवरुद्ध होने वाले लेखन का सामना नहीं कर सकता है, क्या मैं उस अवधि को संशोधित कर सकता हूं जो संग्रह को फिर से साझा करने के लिए अवरुद्ध कर दिया जाएगा? हां, लेकिन हम उम्मीद नहीं करते हैं कि इस विकल्प का अक्सर उपयोग किया जाएगा क्योंकि डिफ़ॉल्ट रूप से रीशर्डिंग ऑपरेशन नए संग्रह में कटओवर करने का प्रयास करेगा जब यह अनुमान लगाया जाएगा कि कटओवर 1 सेकंड से कम समय में पूरा किया जा सकता है। यदि आपका एप्लिकेशन 2 सेकंड के लिए रीशर्ड किए जा रहे संग्रह को अवरुद्ध किए जाने वाले लेखन का सामना नहीं कर सकता है, तो आप केवल 1 सेकंड के लिए लिखने को ब्लॉक करने के लिए reshardingCriticalSectionTimeoutMillis पैरामीटर को संशोधित कर सकते हैं। कृपया ध्यान रखें कि इस मान को कम करने से रीशार्डिंग ऑपरेशन निरस्त होने की संभावना बढ़ जाती है क्योंकि यह टाइमआउट को कम कर देता है, फिर से शेयरिंग ऑपरेशन कटओवर को पूरा करने के लिए महत्वपूर्ण सेक्शन की प्रतीक्षा कर सकता है। निम्नलिखित आदेश चलाएँ: db.adminCommand({ setParameter: 1, reshardingCriticalSectionTimeoutMillis: 1000 }) Pexels पर की हेडलाइन तस्वीर मिली। पानुमास निखोमखाई
