Una breve nota, más bien para mí, sobre pequeños trucos para la recuperación de datos en Elasticsearch. Cómo corregir el índice rojo si no hay copia de seguridad, qué hacer si eliminé los documentos y no queda ninguna copia; desafortunadamente en la documentación oficial no mencionan estas características.
Copias de seguridad
Lo primero que debe hacer es configurar copias de seguridad de datos importantes. Cómo se hace esto se describe en la
documentación oficial .
En general, nada complicado. En la versión más simple, cree una bola en otro servidor, móntela en todos los nodos elásticos de cualquier manera conveniente (nfs, smbfs, lo que sea). Luego, use cron, su aplicación o cualquier cosa para enviar solicitudes de instantáneas periódicas.
La primera instantánea será larga, las siguientes contendrán solo el delta entre los estados del índice. Tenga en cuenta que si periódicamente realiza una
fusión forzada , el delta será enorme y, en consecuencia, el tiempo que
lleva crear una instantánea será como la primera vez.
Que considerar:
- Compruebe el estado de las copias de seguridad, por ejemplo, utilizando _cat:
curl localhost:9200/_cat/snapshots/ yourbackuprepo / . Las instantáneas parciales o fallidas no son su hermano. - Comenzando con ES 6.x, el elástico es muy exigente en los encabezados de solicitud. Si los hace manualmente (no a través de la API), verifique que tenga
Content-Type: application/json , de lo contrario, todas sus solicitudes simplemente se interrumpirán y no se realizará la copia de seguridad - La instantánea no se puede restaurar a un índice abierto. Debe cerrarse o quitarse primero. Sin embargo, puede restaurar la instantánea lado a lado utilizando rename_pattern, rename_replacement ( consulte el ejemplo en el dock ). Además, cuando se restaura una instantánea, también se restaura su configuración, incluidos los alias, el número de réplicas, etc. Si no necesita esto, agregue index_settings ( vea el dock para ver un ejemplo ) con los cambios necesarios en la solicitud de restauración.
- Los repositorios (bolas) con instantáneas se pueden conectar a más de un clúster y restaurar instantáneas de cualquier clúster a cualquier otro. Lo principal es que las versiones elásticas son compatibles.
En general, mire la documentación, allí este tema se divulga más o menos.
Elasticdump
Una pequeña utilidad en nodejs que le permite copiar datos de un índice a otro índice, clúster, archivo, stdout.
Por cierto, la salida a un archivo o stdout se puede usar como un método de copia de seguridad alternativo: la salida es un json válido regular (algo así como el volcado de sql), que se puede reutilizar como desee. Por ejemplo, puede pegar la salida en una tubería, donde su script de alguna manera transformará los datos y los enviará a otro repositorio, como clickhouse. Las conversiones js más simples se pueden hacer directamente por elasticdump, hay una clave correspondiente
--transformar . En general, un vuelo de fantasía.
De las trampas:
- Como método de respaldo, es mucho más lento que las instantáneas. Además, la copia de seguridad se extiende con el tiempo, por lo que el resultado en un índice que cambia con frecuencia puede ser inconsistente. Tener en cuenta.
- No use nodejs del repositorio de Debian, hay una versión demasiado antigua que afecta negativamente la estabilidad de las herramientas.
- La estabilidad puede variar, especialmente si una de las partes está sobrecargada. No intente hacer una copia de seguridad de un servidor a otro ejecutando la herramienta en la máquina de oficina; todo el tráfico fluirá a través de ella.
- Higo copiando mapeos. Si tiene algo complicado allí, cree el índice manualmente y solo luego complete los datos en él.
- A veces tiene sentido cambiar el tamaño del fragmento (parámetro --limit). Esta opción afecta directamente la velocidad de copia.
Para fusionar una gran cantidad de índices al mismo tiempo, hay una multielasticdump con un conjunto simplificado de opciones, pero todos los índices se combinan en paralelo.
Nota! El autor de la utilidad dijo que ya no tiene tiempo para dar soporte, por lo que el
programa está buscando un nuevo responsable .
Por experiencia personal: utilidad útil, rescatada más de una vez. La velocidad y la estabilidad son más o menos, me gustaría un reemplazo adecuado, pero hasta ahora no hay nada en el horizonte.
Índice de verificación
Entonces, comenzamos a acercarnos al lado oscuro. Situación: el índice se ha vuelto rojo. En los registros: algo salió mal, el cheque no coincide con la cantidad, probablemente tenga una memoria o disco:
org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)Por supuesto, esto nunca sucede con los administradores de la madre, porque tienen hardware de gama alta con triple replicación, memoria superECC con corrección de absolutamente todos los niveles de error sobre la marcha y, en general, las instantáneas se configuran cada segundo.
Pero la realidad desafortunadamente a veces suscita tales opciones, cuando la copia de seguridad fue relativamente larga (si tiene indexados gigabytes por hora, ¿la copia de seguridad es demasiado antigua hace 2 horas?), No hay lugar para restaurar los datos, la replicación no tuvo tiempo y cosas así.
Por supuesto, si hay una instantánea, copia de seguridad o similar. - Excelente, despliegue y no se preocupe. Y si no? Afortunadamente, al menos algunos de los datos aún se pueden guardar.
En primer lugar, cierre el índice y / o apague el elástico, haga una copia de seguridad del fragmento fallido.
Lucene (es decir, funciona como backend en elasticsearch) tiene un maravilloso método CheckIndex. Solo necesitamos convocarlo sobre un fragmento roto. Lucene verificará todos sus segmentos y eliminará los dañados. Sí, se perderán datos, pero al menos no todo. Aunque hay qué suerte.
Hay al menos 2 formas.
Método 1: directamente en el sitio
Un guión tan simple nos ayudará.
Al llamarlo sin parámetros, obtenemos algo como esto:
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.
En realidad, podemos simplemente ejecutar la prueba de índice o hacer que CheckIndex lo "arregle", eliminando todo lo que esté dañado.
El índice de Lucene vive aproximadamente de la misma manera: / var / lib / elasticsearch / node / 0 / indices / str4ngEHashVa1uE / 0 / index /, donde 0 y 0 son el número de nodo en el servidor y el número del fragmento en el nodo. El valor aterrador entre ellos, el nombre interno del índice, se puede obtener de la salida de curl localhost: 9200 / _cat / indices.
Normalmente hago una copia a otro directorio y la reparo en el lugar. Luego reinicio elasticsearch. Como regla general, todo se recoge, aunque con pérdida de datos. A veces, el índice todavía no quiere ser leído debido a los archivos * corruptos * en la carpeta de fragmentos. Muévalos a un lugar seguro por un tiempo.
Método 2: Lucas
(imagen de Internet)
Hay una gran utilidad para trabajar con Lucene
llamada Luke .
Todavía es más simple aquí. Descubra la versión Lucene de su búsqueda elástica:
$ 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" }
Toma la misma versión de Luke. Abrimos en él un índice (copia, por supuesto) con un daw
No abra IndexReader (al abrir un índice dañado) . A continuación, haga clic en Herramientas / Verificar índice. Primero recomiendo correr en seco, y solo luego en el modo de reparación. Otras acciones son similares: vuelva a copiar el elástico, reinicie / abra el índice.
Recuperar documentos borrados
Situación: realizó una consulta destructiva que eliminó muchos / todos los datos que necesita. Y ningún lugar para restaurar, o muy caro. Bueno, por supuesto, SSZB dice que no hay copias de seguridad, pero esto también sucede.
Desafortunadamente o afortunadamente, Lucene nunca elimina nada directamente. Su filosofía está más cerca de CoW, por lo que los datos eliminados no se eliminan realmente, sino que solo se marcan como eliminados. La eliminación en sí ocurre durante la optimización del índice: los datos en vivo de los segmentos se copian en segmentos recién creados, los segmentos antiguos simplemente se eliminan. En general, aunque el estado del índice eliminado no es 0, hay posibilidades de eliminarlo.
$ 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
Después de la fuerza de fusión no hay posibilidad.
Entonces, antes que nada, cierre el índice, detenga el elástico, copie el índice (archivos) en un lugar seguro.
No es posible extraer un documento individual eliminado. Solo puede recuperar todos los documentos eliminados en el segmento especificado.
Para las versiones Lucene debajo de 4, todo es muy simple. La API de Lucene tiene una función llamada undeleteAll. Puedes llamarla directamente desde
Luke desde el párrafo anterior.
Para las versiones más nuevas, por desgracia, la funcionalidad se redujo. Pero todavía hay un camino. La información sobre documentos en vivo se almacena en archivos * .liv. Sin embargo, simplemente eliminarlos hará que el índice sea ilegible. Es necesario corregir el archivo segmentos_N para que se olvide por completo de su existencia.
Abra el archivo segmentos_N (N es un número entero) en su editor Hex favorito. La
documentación oficial nos ayudará a navegarlo:
segments_N: Header, LuceneVersion, Version, NameCounter, SegCount, MinSegmentLuceneVersion, <SegName, SegID, SegCodec, DelGen, DeletionCount, FieldInfosGen, DocValuesGen, UpdatesFiles>SegCount, CommitUserData, Footer
De todo esto, necesitamos los valores de DelGen (Int64) y DeletionCount (Int32). El primero debe ser igual a -1 y el segundo 0.
No es difícil encontrarlos, están justo detrás de SegCodec, que es una cadena muy conspicua como Lucene62. En esta captura de pantalla puede ver que DelGen tiene un valor de 3 y DeletionCount - 184614. Reemplace el primero con 0xFFFFFFFFFFFFFFFF, y el segundo con 0x00000000. Repita para todos los segmentos necesarios, guardar.
Sin embargo, el índice fijo no querrá cargarse, citando un error de suma de verificación. Todavía es más simple aquí. Tome Luke, cargue el índice con el IndexReader deshabilitado, Herramientas / Verificar índice. Realizamos una prueba de funcionamiento e inmediatamente detectamos que los segmentos_N están dañados. Se espera tal y tal verificación, pero se recibe tal y tal.
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) : expected=51fbdb5c actual=6e964d17
¡Tonterías! Tomamos la suma de verificación esperada y la ingresamos en los últimos 4 bytes del archivo.
Guardar. Ejecutamos CheckIndex nuevamente para asegurarnos de que todo esté bien y que el índice se esté cargando.
Et voilà!