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.

[ec2-user@myfakeserver ~]$ curl http://elasticsearch.myfakecluster.com:9200/_cluster/health?pretty
{
  "cluster_name" : "myfakecluster",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 6,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 44,
  "active_shards" : 88,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 2,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 97.77777777777777
}

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.

[ec2-user@myfakeserver ~]$ curl -s http://elasticsearch.myfakecluster.com:9200/_cat/nodes?v
ip            heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
10.10.13.74            62          69   1    0.01    0.01     0.00 m         *      i-00e943d383ac0e36a
10.10.12.224           10          74   0    0.00    0.00     0.00 di        -      i-0fb30da02fa44654f
10.10.14.191           17          68   1    0.30    0.16     0.05 m         -      i-0c3f5e9ffe51580de
10.10.13.26            10          75   0    0.00    0.00     0.00 di        -      i-088d4398987bbcbe4
10.10.14.79            21          71   0    0.00    0.00     0.00 di        -      i-0d02b207abeb67c6b
10.10.12.4             34          68   1    0.04    0.03     0.00 m         -      i-087e0c009c10493d6

Continuar leyendo «Cómo lidiar con unassigned shards en Elasticsearch»

Reemplazar un data nodo de Elasticsearch de forma segura

Es probable que en alguna ocasión necesitemos reemplazar uno de nuestros nodos de datos del cluster de Elasticsearch. Una opción (a lo loco, y nada recomendable) sería directamente eliminar el nodo, y añadir uno nuevo, el cual, en algún momento se sincronizará con el cluster. Obviamente lo malo de esta opción, es que el cluster quedará en status yellow o red mientras no termine la sincronización.

Una buena opción (probado en un ES 5.6.3) para hacer de este proceso, un proceso seguro y controlado, es como primer paso, quitar el nodo del cluster, esperar a que los shards (primarios y réplicas) se re-asignen, y una vez tengamos el nodo desacoplado del cluster, reemplazarlo. La idea es continuar con el cluster en «green» durante todo el proceso.

A continuación los pasos.

Continuar leyendo «Reemplazar un data nodo de Elasticsearch de forma segura»