elasticsearch recovery

Elasticsearch no se pudo recuperar después del bloqueo



recovery (1)

Se salió del espacio de disco y eso atornilló los fragmentos de la cubierta elástica. Tres nodos ahora están en rojo, dos se recuperaron y su estado es amarillo. ES ejecuta un 150% en la CPU y tiene mucha memoria, tratando de recuperarlos. Pero parece que hay algún conflicto de coincidencia de versión.

Aclaré el espacio en disco y borré el translog de un fragmento para detener la carga desde translog. ¡Pero sorprendentemente el translog se crea de nuevo!

Comparta cómo puedo detener este intento de recuperación de translog y reanudar las operaciones de índice normales. No quiero borrar los datos del fragmento.

[2014-10-31 03:11:43,742][WARN ][cluster.action.shard ] [Angela Cairn] [western_europe][4] sending failed shard for [western_europe][4], node[x5M73qVXS5eZIBdz40boEg], [P], s[INITIALIZING], indexUUID [wy-tIJqdQiynz5SGQ2IrGA], reason [Failed to start shard, message [IndexShardGatewayRecoveryException[[western_europe][4] failed to recover shard]; nested: ElasticsearchException[failed to read [tweet][527924645014818817]]; nested: ElasticsearchIllegalArgumentException[No version type match [101]]; ]] [2014-10-31 03:11:43,742][WARN ][cluster.action.shard ] [Angela Cairn] [western_europe][4] received shard failed for [western_europe][4], node[x5M73qVXS5eZIBdz40boEg], [P], s[INITIALIZING], indexUUID [wy-tIJqdQiynz5SGQ2IrGA], reason [Failed to start shard, message [IndexShardGatewayRecoveryException[[western_europe][4] failed to recover shard]; nested: ElasticsearchException[failed to read [tweet][527924645014818817]]; nested: ElasticsearchIllegalArgumentException[No version type match [101]]; ]] [2014-10-31 03:11:43,859][WARN ][indices.cluster ] [Angela Cairn] [western_europe][2] failed to start shard org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [western_europe][2] failed to recover shard at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:269) at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: org.elasticsearch.ElasticsearchException: failed to read [tweet][527936245440065536] at org.elasticsearch.index.translog.Translog$Index.readFrom(Translog.java:511) at org.elasticsearch.index.translog.TranslogStreams.readTranslogOperation(TranslogStreams.java:52) at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:241) ... 4 more Caused by: org.elasticsearch.ElasticsearchIllegalArgumentException: No version type match [116] at org.elasticsearch.index.VersionType.fromValue(VersionType.java:307) at org.elasticsearch.index.translog.Translog$Index.readFrom(Translog.java:508)


Primero, verifique que realmente no haya problemas con los fragmentos en sí mismos. cd al directorio yout /usr/share/elasticsearch/lib o equivalente, y use el CheckIndex de Lucene de la siguiente manera:

java -cp "*" -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex /var/lib/elasticsearch/<ES-NAME>/nodes/<NODE-NUMBER>/indices/<INDEX-NAME>/<SHARD-NUMBER/index/

Esto verificará si hay fragmentos de fragmentos y tardará un tiempo si los fragmentos son grandes.

Tenga en cuenta que si obtiene el classpath de Java incorrecto, faltarán algunos archivos jar requeridos y CheckIndex puede arrojar errores y reclamar erróneamente que todos los segmentos en el shard están rotos, así que lea el resultado cuidadosamente.

Si hay problemas con un fragmento y no tiene otra forma de restaurarlo, ejecutar el mismo comando con el argumento -fix arreglará el fragmento pero perderá datos . CheckIndex le advertirá cuántos documentos (si corresponde) puede perder del fragmento.

Si CheckIndex informa que todo está bien con el fragmento, entonces con suerte su problema estará solo en el translog. El registro de transacciones es un registro de escritura anticipada que ElasticSearch utiliza para la atomicidad. Después de un bloqueo, ES intentará restaurar un fragmento, incluidas las escrituras que aún no se han enviado al índice del fragmento. Estos están en el translog, por lo que los perderá si los elimina . Eso, sin embargo, es mucho mejor que perder el fragmento. En su caso, el translog ya aparece dañado, y no sé de ninguna manera para recuperarlo.

Para eliminar el registro de transacciones dañado que se utiliza para la recuperación, simplemente elimine el translog eliminando los archivos translog en /var/lib/elasticsearch/<ES-NAME>/nodes/<NODE-NUMBER>/indices/<INDEX-NAME>/<SHARD-NUMBER>/translog/ para cada fragmento relevante para cada nodo afectado . La última parte es importante porque puede estar viendo que el clúster intenta regenerar el translog de un fragmento desde otro nodo después de eliminarlo de uno.

Los fragmentos deberían inicializarse correctamente, aunque, como de costumbre, puede tardar un tiempo en completarse.