लोचदार खोज हॉट बैकअप रणनीतियों

Question

कोई दिलचस्प होगा अगर कोई ElasticSearch के लिए अपनी सर्वश्रेष्ठ 'हॉट-बैकअप' रणनीतियों को साझा कर सके।

इसके अलावा, इस समस्या से संबंधित टूल और पुस्तकालयों को साझा करने में संकोच न करें और सहायता कर सकते हैं।

अपडेटेडः आपकी प्रतिक्रिया के लिए @ javanna धन्यवाद, यह काफी पूर्ण है और आगे के कार्यों के लिए अच्छी दिशा प्रदान करता है।

मैंने एक छोटा सा शोध भी किया और कुछ लेख/चर्चाएं मिलीं जो किसी के हित में मदद कर सकती हैं। एक Elasticsearch 1.0 है:

• Elasticsearch backup strategies
• Backup/restore Elasticsearch index और related snippet on github:gist
• Elastic Search Backup and Recovery चर्चा

अद्यतन (पॉल स्मिथ की टिप्पणी की जांच, यह भी वह अपने tool for verifying indexes एक उपयोगी लिंक साझा किया) "आधिकारिक" बैकअप समाधान - Snapshot/Restore API और यह अब इसका एकमात्र सही तरीका है। लोचदार खोज मास्टर शर्ड्स की पहचान करेगी और स्थिरता के बारे में परवाह करेगी। बैकअप बढ़ता जा रहा है, इसलिए आप इसे जितनी बार चाहें उतनी तेजी से कर पाएंगे।

Answer 1

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

मैं Gateway मॉड्यूल देखता हूं, जिसके माध्यम से आप अनुक्रमणिका और क्लस्टर मेटाडेटा को सहेज सकते हैं। गेटवे के विभिन्न प्रकार हैं। उदाहरण के लिए मैं Shared FS पर देखता हूं, जो आपको इंडेक्स और मेटाडेटा को फ़ाइल सिस्टम में कॉपी करने की अनुमति देता है जो आपके सभी नोड्स के बीच साझा किया जाता है। आप Gateway Snapshot API के माध्यम से मैन्युअल रूप से स्नैपशॉट भी प्रारंभ कर सकते हैं।

इसके अलावा, आप index.translog.disable_flush index setting के माध्यम से फ़्लश करने के बाद डेटा निर्देशिका (प्रत्येक नोड पर) की एक प्रति बना सकते हैं। इस तरह आप यह सुनिश्चित करेंगे कि प्रतिलिपि बनाते समय कोई ल्यूसीन प्रतिबद्धता जारी नहीं की जाएगी। प्रतिलिपि बनाने के बाद आपको फिर से फ्लश सक्षम करने की आवश्यकता है।

अद्यतन स्थानीय एक को छोड़कर

सभी प्रवेश द्वार प्रकार अमान्य हो जाने और उसे भावी संस्करण में हटा दिया जाएगा। Elasticsearch 1.0 बेहतर बैकअप समाधान के साथ जारी किया जाएगा।

Answer 2

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

यही कारण है कि मुझे लोचदार खोज में प्रतिकृतियां स्थापित करना पसंद नहीं है, यह एक दर्द है कि कौन सी नोड को प्रतिकृति मिलती है, और यदि आप भविष्य में संगठन को पुनर्व्यवस्थित करना चाहते हैं, तो आपको मूल रूप से एक टन से गुजरना होगा हुप्स। लोचदार खोज दृश्यों के पीछे पुनर्विक्रय का एक टन करता है, और आपके लिए सबकुछ करने की कोशिश करता है। जो अच्छा हो सकता है ..यदि आपके पास शक्तिशाली सर्वर हैं और परवाह नहीं है कि क्या हो जाता है .. लेकिन अन्यथा दर्द हो सकता है।