इलास्टिसर्च के साथ छोटी चाल

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

बैकअप

पहली बात यह है कि महत्वपूर्ण डेटा का बैकअप सेट किया गया है। यह कैसे किया जाता है यह आधिकारिक दस्तावेज में वर्णित है।

सब सब में, कुछ भी जटिल नहीं है। सरलतम संस्करण में, किसी अन्य सर्वर पर एक गेंद बनाएं, इसे किसी भी सुविधाजनक तरीके से सभी लोचदार नोड्स पर माउंट करें (nfs, smbfs, जो भी हो)। इसके बाद, समय-समय पर स्नैपशॉट के लिए अनुरोध भेजने के लिए क्रॉन, अपने एप्लिकेशन या किसी भी चीज़ का उपयोग करें।

पहला स्नैपशॉट लंबा होगा, बाद वाले में सूचकांक के राज्यों के बीच केवल डेल्टा होगा। ध्यान दें कि यदि आप समय-समय पर एक संदंश करते हैं , तो डेल्टा विशाल होगा और, तदनुसार, स्नैपशॉट बनाने में लगने वाला समय पहली बार की तरह होगा।

क्या विचार करें:

• बैकअप की स्थिति जांचें, उदाहरण के लिए _cat: curl localhost:9200/_cat/snapshots/ yourbackuprepo / का उपयोग करके। आंशिक या विफल स्नैपशॉट आपके भाई नहीं हैं।
• ईएस 6.x के साथ शुरू, लोचदार बहुत अनुरोध हेडर पर मांग कर रहा है। यदि आप उन्हें मैन्युअल रूप से (एपीआई के माध्यम से नहीं) करते हैं, तो जांचें कि आपके पास Content-Type: application/json , अन्यथा आपके सभी अनुरोध बस टूट जाते हैं और बैकअप नहीं होता है
• स्नैपशॉट को एक खुले सूचकांक में बहाल नहीं किया जा सकता है। इसे पहले बंद या हटाया जाना चाहिए। हालाँकि, आप rename_pattern, rename_replacement ( गोदी में उदाहरण देखें ) का उपयोग करके स्नैपशॉट पक्ष को पुनर्स्थापित कर सकते हैं । इसके अलावा, जब एक स्नैपशॉट को पुनर्स्थापित किया जाता है, तो इसकी सेटिंग्स भी पुनर्स्थापित की जाती हैं, जिसमें उपनाम, प्रतिकृतियां की संख्या आदि शामिल हैं। यदि आपको इसकी आवश्यकता नहीं है, तो पुन: अनुरोध करने के लिए आवश्यक परिवर्तनों के साथ index_settings ( उदाहरण के लिए डॉक देखें) जोड़ें।
• स्नैपशॉट के साथ रिपोज (गेंद) एक से अधिक क्लस्टर से जुड़ा हो सकता है और स्नैपशॉट को किसी भी क्लस्टर से किसी अन्य में पुनर्स्थापित कर सकता है। मुख्य बात यह है कि लोचदार संस्करण संगत हैं।

सामान्य तौर पर, दस्तावेज़ीकरण देखें, वहां इस विषय का कमोबेश खुलासा होता है।

Elasticdump

नोडज पर एक छोटी सी उपयोगिता जो आपको एक इंडेक्स से दूसरे इंडेक्स, क्लस्टर, फाइल, स्टडआउट में डेटा कॉपी करने की अनुमति देती है।

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

नुकसान की:

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

एक ही समय में बड़ी संख्या में सूचकांकों को मर्ज करने के लिए, विकल्पों के सरलीकृत सेट के साथ मल्टीएलेस्टैम्पड है, लेकिन सभी सूचकांक समानांतर में विलय होते हैं।

नोट! उपयोगिता के लेखक ने कहा कि उसके पास अब समर्थन करने का समय नहीं है, इसलिए कार्यक्रम एक नए अनुचर की तलाश कर रहा है ।

व्यक्तिगत अनुभव से: उपयोगी उपयोगिता, एक से अधिक बार बचाया। गति और स्थिरता इतनी है, इसलिए मैं पर्याप्त प्रतिस्थापन चाहूंगा, लेकिन अभी तक कुछ भी क्षितिज पर नहीं है।

CheckIndex

तो, हम अंधेरे पक्ष का रुख करना शुरू करते हैं। स्थिति: सूचकांक लाल हो गया है। लॉग में - कुछ गलत हो गया, चेक राशि से मेल नहीं खाता, आपको संभवतः एक मेमोरी या डिस्क मिली:

org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)

बेशक, यह माँ के प्रवेश के साथ कभी नहीं होता है, क्योंकि उनके पास ट्रिपल प्रतिकृति के साथ टॉप-एंड हार्डवेयर है, मक्खी पर बिल्कुल सभी त्रुटि स्तरों के सुधार के साथ सुपरईसीसी मेमोरी, और आमतौर पर हर सेकंड स्नैपशॉट कॉन्फ़िगर किए जाते हैं।

लेकिन वास्तविकता दुर्भाग्य से कभी-कभी ऐसे विकल्पों का संकेत देती है, जब बैकअप अपेक्षाकृत लंबा था (यदि आपके पास प्रति घंटे गीगाबाइट्स अनुक्रमित हैं, तो बैकअप 2 घंटे पहले भी पुराना है?), डेटा को पुनर्स्थापित करने के लिए कोई जगह नहीं है, प्रतिकृति के पास समय और सामान नहीं था।

बेशक, अगर कोई स्नैपशॉट, बैकअप या पसंद है। - बहुत बढ़िया, बाहर रोल और चिंता मत करो। और अगर नहीं? सौभाग्य से, कम से कम कुछ डेटा अभी भी बचाया जा सकता है।

सबसे पहले, इंडेक्स को बंद करें और / या लोचदार को बंद करें, असफल शार्प की एक बैकअप प्रतिलिपि बनाएं।

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

कम से कम 2 तरीके हैं।

विधि 1: सीधे साइट पर

इस तरह की एक सरल स्क्रिप्ट हमारी मदद करेगी।

 #!/bin/bash pushd /usr/share/elasticsearch/lib java -cp lucene-core*.jar -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex "$@" popd 

मापदंडों के बिना इसे कॉल करने पर, हमें कुछ इस तरह मिलता है:

 ERROR: index path not specified Usage: java org.apache.lucene.index.CheckIndex pathToIndex [-exorcise] [-crossCheckTermVectors] [-segment X] [-segment Y] [-dir-impl X] -exorcise: actually write a new segments_N file, removing any problematic segments -fast: just verify file checksums, omitting logical integrity checks -crossCheckTermVectors: verifies that term vectors match postings; THIS IS VERY SLOW! -codec X: when exorcising, codec to write the new segments_N file with -verbose: print additional details -segment X: only check the specified segments. This can be specified multiple times, to check more than one segment, eg '-segment _2 -segment _a'. You can't use this with the -exorcise option -dir-impl X: use a specific FSDirectory implementation. If no package is specified the org.apache.lucene.store package will be used. **WARNING**: -exorcise *LOSES DATA*. This should only be used on an emergency basis as it will cause documents (perhaps many) to be permanently removed from the index. Always make a backup copy of your index before running this! Do not run this tool on an index that is actively being written to. You have been warned! Run without -exorcise, this tool will open the index, report version information and report any exceptions it hits and what action it would take if -exorcise were specified. With -exorcise, this tool will remove any segments that have issues and write a new segments_N file. This means all documents contained in the affected segments will be removed. This tool exits with exit code 1 if the index cannot be opened or has any corruption, else 0. 

वास्तव में, हम या तो केवल इंडेक्स टेस्ट चला सकते हैं, या चेकइंडेक्स "फिक्स" कर सकते हैं, जो सब कुछ क्षतिग्रस्त हो गया है।

Lutsen इंडेक्स एक समान तरीके से रहता है: / var / lib / elasticsearch / nodes / 0 / indices / str4ngEHashVa1uE / 0 / index /, जहां 0 और 0 सर्वर पर नोड संख्या और नोड पर शार्प की संख्या है। उनके बीच का डरावना मूल्य - सूचकांक का आंतरिक नाम - कर्ल लोकलहोस्ट के आउटपुट से प्राप्त किया जा सकता है: 9200 / _cat / सूचकांक।

मैं आमतौर पर किसी अन्य निर्देशिका की प्रतिलिपि बनाता हूं, और इन-प्लेस की मरम्मत करता हूं। तब मैं इलास्टिक्स खोज पुनः आरंभ करता हूं। एक नियम के रूप में, सब कुछ उठाया जाता है, डेटा हानि के साथ। कभी-कभी सूचकांक अभी भी फ़ोल्डर में * दूषित * फ़ाइलों के कारण पढ़ा नहीं जा सकता है। उन्हें थोड़ी देर के लिए सुरक्षित स्थान पर ले जाएं।

विधि 2: ल्यूक

(तस्वीर इंटरनेट से)

ल्यूकिन नामक ल्यूक के साथ काम करने के लिए एक महान उपयोगिता है।

यह अभी भी यहाँ सरल है। अपनी इलास्टिक्स खोज से ल्यूसीन संस्करण का पता लगाएं:

 $ curl localhost:9200 { "name" : "node00", "cluster_name" : "main", "cluster_uuid" : "UCbEivvLTcyWSQElOipgTQ", "version" : { "number" : "6.2.4", "build_hash" : "ccec39f", "build_date" : "2018-04-12T20:37:28.497551Z", "build_snapshot" : false, "lucene_version" : "7.2.1", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" } 

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

हटाए गए दस्तावेज़ पुनर्प्राप्त करें

स्थिति: आपने एक विनाशकारी क्वेरी का प्रदर्शन किया जो आपके लिए आवश्यक बहुत सारे / सभी डेटा को हटा देती है। और कहीं भी बहाल करने के लिए, या बहुत महंगा नहीं है। ठीक है, ज़ाहिर है, SSZB कि कोई बैकअप नहीं है, लेकिन यह भी होता है।

दुर्भाग्य से या सौभाग्य से, Lucene कभी भी सीधे कुछ भी नहीं निकालता है। इसका दर्शन CoW के करीब है, इसलिए हटाए गए डेटा को वास्तव में हटाया नहीं गया है, लेकिन केवल हटाए गए के रूप में चिह्नित किया गया है। इंडेक्स ऑप्टिमाइज़ेशन के दौरान ही डिलीट होता है - सेगमेंट के लाइव डेटा को नए बनाए गए सेगमेंट में कॉपी किया जाता है, पुराने सेगमेंट को बस डिलीट कर दिया जाता है। सामान्य तौर पर, जबकि हटाए गए सूचकांक की स्थिति 0 नहीं है, इसे बाहर निकालने की संभावना है।

 $ curl localhost:9200/_cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open data.0 R0fgvfPnTUaoI2KKyQsgdg 5 1 7238685 1291566 45.1gb 22.6gb 

जोर लगाने के बाद कोई मौका नहीं है।

इसलिए, सबसे पहले, सूचकांक को बंद करें, लोचदार को रोकें, सूचकांक (फाइलों) को एक सुरक्षित स्थान पर कॉपी करें।

व्यक्तिगत हटाए गए दस्तावेज़ को बाहर निकालना संभव नहीं है। आप निर्दिष्ट खंड में केवल हटाए गए सभी दस्तावेजों को पुनर्प्राप्त कर सकते हैं।

4 से नीचे के संस्करणों के लिए, सब कुछ बहुत सरल है। Lucene API में एक फ़ंक्शन है जिसे undeleteAll कहा जाता है। आप उसे पिछले पैराग्राफ से सीधे ल्यूक से बुला सकते हैं।

नए संस्करणों के लिए, अफसोस, कार्यक्षमता में कटौती की गई थी। लेकिन फिर भी एक रास्ता अभी भी है। लाइव दस्तावेजों के बारे में जानकारी * .liv फ़ाइलों में संग्रहीत है। हालांकि, बस उन्हें हटाने से सूचकांक अपठनीय हो जाएगा। यह सेगमेंट्स-फ़ाइल को सही करने के लिए आवश्यक है ताकि यह पूरी तरह से उनके अस्तित्व के बारे में भूल जाए।

अपने पसंदीदा हेक्स संपादक में सेगमेंट्स फ़ाइल (एन एक पूर्णांक है) खोलें। आधिकारिक प्रलेखन हमें इसे नेविगेट करने में मदद करेगा:

 segments_N: Header, LuceneVersion, Version, NameCounter, SegCount, MinSegmentLuceneVersion, <SegName, SegID, SegCodec, DelGen, DeletionCount, FieldInfosGen, DocValuesGen, UpdatesFiles>SegCount, CommitUserData, Footer 

इस सब से, हमें डेलजेन (Int64) और डीलेटियनकाउंट (Int32) के मूल्यों की आवश्यकता है। पहले को -1 के बराबर सेट किया जाना चाहिए, और दूसरा 0 पर।



उन्हें ढूंढना मुश्किल नहीं है, वे SegCodec के ठीक पीछे हैं, जो Lucene62 की तरह एक बहुत ही विशिष्ट स्ट्रिंग है। इस स्क्रीनशॉट में आप देख सकते हैं कि DelGen का मूल्य 3 है, और DeletionCount - 184614। पहला बदलें 0xFFFFFFFFFFFFFFFFFF से, और दूसरा 0x00000000 से बदलें। सभी आवश्यक खंडों के लिए दोहराएं, सहेजें।

हालाँकि, फिक्स्ड इंडेक्स चेकसम त्रुटि का हवाला देते हुए लोड नहीं करना चाहेगा। यह अभी भी यहाँ सरल है। ल्यूक को लें, इंडेक्स को अक्षम इंडेक्सरेडर, टूल्स / चेक इंडेक्स के साथ लोड करें। हम एक परीक्षण चलाते हैं और तुरंत पकड़ लेते हैं कि सेगमेंट_N क्षतिग्रस्त है। इस तरह के चेक की उम्मीद की जाती है, लेकिन ऐसा और ऐसा प्राप्त होता है।

 Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) : expected=51fbdb5c actual=6e964d17 

बकवास! हम अपेक्षित चेकसम को लेते हैं और इसे फ़ाइल के अंतिम 4 बाइट्स में दर्ज करते हैं।



सहेजें। हम CheckIndex को फिर से चलाते हैं ताकि यह सुनिश्चित हो सके कि सब कुछ ठीक है और इंडेक्स लोड हो रहा है।

Et voilà!