Cómo lidiar con unassigned shards en Elasticsearch


Lo primero es lo primero, saber qué significa el estado del cluster de elasticsearch:

  • Green: Cluster 100% operacional con todos los shards, tanto primarios como réplicas asignados.
  • Yellow: Todos los shards primarios asignados, pero al menos hay problemas con una réplica. El funcionamiento de las búsquedas no se ve afectado, pero la alta disponibilidad del cluster podría estar comprometida.
  • Red: Al menos un shard primario tiene problemas. Tus búsquedas devolverán resultados incompletos y el indexado podría devolver alguna excepción.

Fuentes: [elastic.co] [chrissimpson.co.uk]

Red cluster. ¿Y ahora qué?

En el siguiente ejemplo, vemos un cluster en estado RED, con 2 shards no asignados.

Muchas de las ocasiones en los que me he encontrado con un cluster con unassigned shards ha sido por falta de espacio en disco, ya sea porque el cluster en sí se estaba quedando sin espacio, o porque había caído alguno de los data nodes. Así pues, tras verificar que no haya problemas de espacio, seguramente deberíamos revisar que el cluster tenga el número y tipo de nodos esperados.

Por cierto, si tienes problemas de espacio, verás que tras eliminar índices no se libera espacio. Esto es debido a cómo Lucene trabaja, que marca los documentos para ser eliminados pero no los elimina hasta que las operaciones de merge internas se ejecutan. Y ésto pasa cuando Lucene decide que pase. Una forma de forzar el merge de los segmentos, únicamente para los índices eliminados es mediante /_forcemerge?only_expunge_deletes=true

Otra llamada que es oro es /_cluster/allocation/explain la cual nos dará la razón del porqué no se han podido asignar los shards. Merece la pena pararse a leer el output.

Asignación manual de shards

Si hemos confirmado que no ha caído ningún nodo y que no tenemos problemas de espacio, pasaremos a revisar los shards.

Algo a remarcar es que Elasticsearch siempre intentará re-assignar los shards “unassigned”, así pues siempre es una buena idea darle un tiempo prudencial al cluster para que trate de solucionar por él mismo los unassigned shards mientras revisamos los logs.

Si queremos forzar a assignar los shards, lo primero que tendremos que hacer es tener claros qué shards estan unassigned, y entender dónde deberían haberse asignado. Podemos usar _cat/shards para listar todos los shards, obteniendo detalles sobre su estado y su tipo (primario o réplica), y mediante grep ver directamente los shards que no están asignados. Recordemos que si al menos uno de los shards es de tipo primary (prirep = p) el cluster estará en status RED.

Del output anterior, nos interesará identificar:

  • El índice (o índices) al que pertenecen los unassigned shards
  • El número de shard

En el ejemplo anterior, tenemos dos índices con unassigned shards.

Empezaremos listando todos los shards del primer índice (fakeindx-20181120 en el ejemplo)

En la salida anterior vemos como fakeindx-20181120 tiene únicamente dos shards (números 0 y 1) con una réplica cada uno. Además, vemos como el shard 1 tiene asignado el shard primario en el nodo instance-0000000020 y su réplica en el nodo instance-0000000021. Así pues, podríamos pensar en asignar la réplica del shard 0 que actualmente está unassigned, también al nodo instance-0000000021. Para ello primero, querríamos confirmar cómo tiene asignados los shards un índice “healthy” del mismo tipo.

Tras confirmar que parece bastante evidente que el shard unassigned debería ir al nodo instance-0000000021, podemos forzar su asignación con _cluster/reroute. Ojo, antes de darle al intro, confirma tu versión de Elasticsearch. Los comandos de este artículo se han probado con la versión 5.6, así que aunque seguramente no varíen mucho entre versiones, vale la pena revisarlo.

La operación anterior debería devolver un OK o en su defecto, el mensaje de error con la explicación de la razón por la que no se ha podido realizar la asignación.

Prueba usar /_cluster/reroute?retry_failed=true si la operación anterior lanza un error referente al máximo de retries.

Fuentes: https://www.elastic.co/blog/red-elasticsearch-cluster-panic-no-longer

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *