ملاحظة قصيرة ، بدلاً عن نفسي ، حول الحيل الصغيرة لاستعادة البيانات في Elasticsearch. كيفية إصلاح الفهرس الأحمر في حالة عدم وجود نسخة احتياطية ، وماذا تفعل إذا قمت بحذف المستندات ، ولم يتبقى نسخة - للأسف في الوثائق الرسمية ، فإنهم صامتون بشأن هذه الميزات.
النسخ الاحتياطية
أول شيء يجب فعله هو إعداد نسخ احتياطية من البيانات المهمة. يتم وصف كيفية القيام بذلك في
الوثائق الرسمية .
الكل في الكل ، لا شيء معقد. في أبسط إصدار ، قم بإنشاء كرة على خادم آخر ، وقم بتثبيتها على جميع العقد المرنة بأي طريقة مناسبة (nfs ، smbfs ، أيا كان). بعد ذلك ، استخدم cron أو تطبيقك أو أي شيء لإرسال طلبات اللقطات الدورية.
ستكون اللقطة الأولى طويلة ، وستحتوي اللقطات اللاحقة فقط على دلتا بين حالات الفهرس. لاحظ أنه إذا كنت تقوم بشكل دوري
بشق ، فإن الدلتا ستكون ضخمة ، وبالتالي ، فإن الوقت
المستغرق لإنشاء لقطة سيكون مثل المرة الأولى.
ما يجب مراعاته:
- تحقق من حالة النسخ الاحتياطية ، على سبيل المثال باستخدام _cat:
curl localhost:9200/_cat/snapshots/ yourbackuprepo / . اللقطات الجزئية أو الفاشلة ليست إخوانك. - بدءًا من ES 6.x ، فإن المرونة مطلوبة جدًا في رؤوس الطلبات. إذا قمت بذلك يدويًا (وليس من خلال واجهة برمجة التطبيقات) ، فتأكد من أن لديك
Content-Type: application/json ، وإلا Content-Type: application/json جميع طلباتك ولن يحدث النسخ الاحتياطي - لا يمكن استعادة اللقطة إلى فهرس مفتوح. يجب إغلاقه أو إزالته أولاً. ومع ذلك ، يمكنك استعادة اللقطة جنبًا إلى جنب باستخدام rename_pattern و rename_replacement ( انظر المثال في المرسى ). بالإضافة إلى ذلك ، عند استعادة لقطة ، تتم استعادة إعداداتها أيضًا ، بما في ذلك الأسماء المستعارة وعدد النسخ المتماثلة وما إلى ذلك. إذا لم تكن بحاجة إلى ذلك ، قم بإضافة index_settings ( راجع المرسى للحصول على مثال ) مع التغييرات اللازمة على طلب الاستعادة.
- يمكن توصيل الريبو (الكرة) مع اللقطات بأكثر من مجموعة واحدة واستعادة اللقطات من أي مجموعة إلى أي مجموعة أخرى. الشيء الرئيسي هو أن الإصدارات المرنة متوافقة.
بشكل عام ، انظر إلى الوثائق ، هناك تم الكشف عن هذا الموضوع إلى حد ما.
تفريغ مطاطي
أداة صغيرة على nodejs تسمح لك بنسخ البيانات من فهرس إلى فهرس آخر ، كتلة ، ملف ، stdout.
بالمناسبة ، يمكن استخدام الإخراج إلى ملف أو stdout كطريقة بديلة للنسخ الاحتياطي - الإخراج هو json صالح منتظم (شيء مثل تفريغ sql) ، والذي يمكن إعادة استخدامه كما تريد. على سبيل المثال ، يمكنك لصق الإخراج في أنبوب ، حيث سيحول النص الخاص بك بطريقة ما البيانات ويرسلها إلى مستودع آخر ، مثل clickhouse. يمكن إجراء أبسط تحويلات js مباشرة عن طريق التفريغ المرن نفسه ، وهناك مفتاح مقابل -
تحويل . بشكل عام ، رحلة خيالية.
من المزالق:
- كطريقة احتياطية ، فهي أبطأ بكثير من اللقطات. بالإضافة إلى ذلك ، يتم تمديد النسخ الاحتياطي بمرور الوقت ، لذلك قد تكون النتيجة على فهرس متغير باستمرار غير متناسقة. ضع في اعتبارك.
- لا تستخدم nodejs من مستودع دبيان ، فهناك نسخة قديمة جدًا تؤثر سلبًا على استقرار الأدوات.
- قد يختلف الاستقرار ، خاصة إذا كان أحد الطرفين زائدًا. لا تحاول النسخ الاحتياطي من خادم إلى آخر عن طريق تشغيل الأداة على الجهاز المكتبي - ستتدفق جميع حركة المرور عبره.
- تعيينات نسخ التين. إذا كان لديك شيء معقد هناك ، فقم بإنشاء الفهرس يدويًا ، ثم املأ البيانات فيه فقط.
- في بعض الأحيان يكون من المنطقي تغيير حجم القطعة (المعلمة - حد). يؤثر هذا الخيار بشكل مباشر على سرعة النسخ.
لدمج عدد كبير من المؤشرات في نفس الوقت ، هناك تفريغ متعدد المواد مع مجموعة مبسطة من الخيارات ، ولكن كل المؤشرات تدمج بالتوازي.
ملاحظة! قال مؤلف الأداة أنه لم يعد لديه الوقت لدعمه ، لذلك
يبحث البرنامج عن مشرف جديد .
من التجربة الشخصية: فائدة مفيدة ، تم إنقاذها أكثر من مرة. السرعة والاستقرار متساويان ، أود الحصول على بديل مناسب ، ولكن حتى الآن لا يوجد شيء في الأفق.
Checkindex
لذا ، نبدأ في الاقتراب من الجانب المظلم. الحالة: أصبح المؤشر باللون الأحمر. في السجلات - حدث خطأ ما ، لا يتطابق الشيك مع المبلغ ، ربما لديك ذاكرة أو قرص:
org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)بالطبع ، لا يحدث هذا أبدًا مع المشرفين الأم ، لأن لديهم أجهزة متطورة مع تكرار ثلاثي ، وذاكرة superECC مع تصحيح جميع مستويات الخطأ على الإطلاق ، ويتم تكوين اللقطات بشكل عام في كل ثانية.
لكن الواقع ، للأسف ، يطالب الواقع أحيانًا بمثل هذه الخيارات ، عندما كانت النسخة الاحتياطية طويلة نسبيًا (إذا كان لديك غيغابايت مفهرسة في الساعة ، فهل النسخ الاحتياطي قديم جدًا قبل ساعتين؟) ، فلا يوجد مكان لاستعادة البيانات ، ولم يكن للنسخ المتماثل وقت وما شابه.
بالطبع ، إذا كان هناك لقطة أو نسخة احتياطية أو ما شابه ذلك. - ممتاز ، طرح ولا تقلق. وإذا لم يكن كذلك؟ لحسن الحظ ، لا يزال من الممكن حفظ بعض البيانات على الأقل.
بادئ ذي بدء ، أغلق الفهرس و / أو أوقف الشريط المرن ، قم بعمل نسخة احتياطية من القشرة الفاشلة.
لوسين (أي أنها تعمل كخلفية في البحث المطاطي) لديها طريقة CheckIndex رائعة. نحتاج فقط إلى استدعائه على قطعة مكسورة. سوف يقوم Lucene بفحص جميع أجزائه وإزالة الأجزاء التالفة. نعم ، ستفقد البيانات ، ولكن ليس على الأقل كل شيء. على الرغم من أن هناك كم محظوظ.
هناك طريقتان على الأقل.
الطريقة الأولى: مباشرة على الموقع
مثل هذا السيناريو البسيط سيساعدنا.
يطلق عليه بدون معلمات ، نحصل على شيء مثل هذا:
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.
في الواقع ، يمكننا ببساطة تشغيل اختبار الفهرس ، أو جعل CheckIndex "يصلح" ذلك ، مما يقطع كل شيء تالف.
يعيش مؤشر Lucene بالطريقة نفسها تقريبًا: / var / lib / elasticsearch / nodes / 0 / indices / str4ngEHashVa1uE / 0 / index / ، حيث يمثل 0 و 0 رقم العقدة على الخادم وعدد القطع على العقدة. يمكن الحصول على القيمة المخيفة بينهما - الاسم الداخلي للمؤشر - من إخراج curl localhost: 9200 / _cat / index.
أقوم عادةً بعمل نسخة إلى دليل آخر وأصلحها في مكانها. ثم أعد تشغيل بحث اللدائن. كقاعدة ، يتم التقاط كل شيء ، وإن كان ذلك مع فقدان البيانات. في بعض الأحيان لا يزال الفهرس لا يريد أن يقرأ بسبب ملفات * تالفة في مجلد الأجزاء. انقلهم إلى مكان آمن لفترة من الوقت.
الطريقة 2: لوقا
(صورة من الإنترنت)
هناك فائدة كبيرة للعمل مع Lucene
تسمى Luke .
لا يزال الأمر أبسط هنا. تعرف على إصدار Lucene من البحث المطاطي الخاص بك:
$ 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" }
خذ نفس نسخة لوقا. نفتح فيه فهرسًا (نسخة من الدورة التدريبية) مع داو
لا تفتح IndexReader (عند فتح فهرس تالف) . بعد ذلك ، انقر فوق أدوات / فحص الفهرس. أولاً أوصي بالتجفيف ، وعندها فقط في وضع الإصلاح. هناك إجراءات أخرى متشابهة - انسخ الشريط المطاطي وأعد / افتح المؤشر.
استرجاع الوثائق المحذوفة
الحالة: قمت بإجراء استعلام مدمر حذف الكثير / جميع البيانات التي تحتاجها. وليس هناك مكان لاستعادة ، أو مكلفة للغاية. حسنًا ، بالطبع ، 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
بعد الهزيمة لا توجد فرصة.
لذا ، أولاً ، أغلق الفهرس ، أوقف المرونة ، انسخ الفهرس (الملفات) إلى مكان آمن.
لا يمكن سحب مستند محذوف فردي. يمكنك فقط استرداد جميع المستندات المحذوفة في الجزء المحدد.
بالنسبة للإصدارات Lucene أقل من 4 ، كل شيء بسيط للغاية. يحتوي API Lucene على وظيفة تسمى undeleteAll. يمكنك الاتصال بها مباشرة من
لوقا من الفقرة السابقة.
للإصدارات الأحدث ، للأسف ، تم قطع الوظائف. ولكن لا يزال هناك طريق. يتم تخزين المعلومات حول المستندات الحية في ملفات * .liv. ومع ذلك ، فإن إزالتها ببساطة ستجعل الفهرس غير قابل للقراءة. من الضروري تصحيح ملف segments_N بحيث ينسى تمامًا وجودها.
افتح ملف segments_N (N عدد صحيح) في محرر Hex المفضل لديك. ستساعدنا
الوثائق الرسمية في تصفحها:
segments_N: Header, LuceneVersion, Version, NameCounter, SegCount, MinSegmentLuceneVersion, <SegName, SegID, SegCodec, DelGen, DeletionCount, FieldInfosGen, DocValuesGen, UpdatesFiles>SegCount, CommitUserData, Footer
من كل هذا ، نحتاج إلى قيم DelGen (Int64) و DeletionCount (Int32). يجب تعيين الأول يساوي -1 ، والثاني 0.
ليس من الصعب العثور عليهم ، فهم خلف SegCodec مباشرة ، وهي سلسلة واضحة للغاية مثل Lucene62. في لقطة الشاشة هذه ، يمكنك رؤية أن DelGen له قيمة 3 ، و DeletionCount - 184614. استبدل الأول بـ 0xFFFFFFFFFFFFFFFF ، والثاني بـ 0x00000000. كرر لجميع الأجزاء الضرورية ، باستثناء.
ومع ذلك ، لن يرغب في تحميل المؤشر الثابت ، مشيرًا إلى خطأ المجموع الاختباري. لا يزال الأمر أبسط هنا. خذ لوقا ، قم بتحميل الفهرس مع تعطيل IndexReader ، أدوات / فحص الفهرس. نجري اختبارًا ونلتقط على الفور أن المقاطع_N معطلة. ومن المتوقع مثل هذا الشيك ، ولكن يتم استلام مثل هذا ومثل.
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) : expected=51fbdb5c actual=6e964d17
هراء! نأخذ المجموع الاختباري المتوقع وأدخله في آخر 4 بايت من الملف.
احفظ. نقوم بتشغيل CheckIndex مرة أخرى للتأكد من أن كل شيء على ما يرام وأن الفهرس قيد التحميل.
Et voilà!