ElasticSearch: fragmentos no asignados, ¿cómo solucionarlo?

sharding master

Question

Tengo un clúster de ES con 4 nodos:

number_of_replicas: 1
search01 - master: false, data: false
search02 - master: true, data: true
search03 - master: false, data: true
search04 - master: false, data: true

Tuve que reiniciar search03, y cuando volvió, se volvió a unir al clúster sin problemas, pero dejó 7 fragmentos sin asignar.

{
  "cluster_name" : "tweedle",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 4,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 15,
  "active_shards" : 23,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 7
}

Ahora mi clúster está en estado amarillo. ¿Cuál es la mejor manera de resolver este problema?

• Eliminar (cancelar) los fragmentos?
• Mueva los fragmentos a otro nodo?
• ¿Asignar los fragmentos al nodo?
• Actualizar ''number_of_replicas'' a 2?
• ¿Algo más completamente?

Curiosamente, cuando se agregó un nuevo índice, ese nodo comenzó a trabajar en él y jugó bien con el resto del clúster, simplemente dejó los fragmentos no asignados por ahí.

Siga con la pregunta: ¿estoy haciendo algo mal para que esto suceda en primer lugar? No tengo mucha confianza en un clúster que se comporta de esta manera cuando se reinicia un nodo.

NOTA: Si está ejecutando un clúster de nodo único por alguna razón, puede que necesite hacer lo siguiente:

curl -XPUT ''localhost:9200/_settings'' -d ''
{
    "index" : {
        "number_of_replicas" : 0
    }
}''

Answer 1

De forma predeterminada, Elasticsearch volverá a asignar fragmentos a los nodos de forma dinámica. Sin embargo, si ha deshabilitado la asignación de fragmentos (quizás reinició sucesivamente y olvidó volver a habilitarlos), puede volver a habilitar la asignación de fragmentos.

# v0.90.x and earlier
curl -XPUT ''localhost:9200/_settings'' -d ''{
    "index.routing.allocation.disable_allocation": false
}''

# v1.0+
curl -XPUT ''localhost:9200/_cluster/settings'' -d ''{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}''

Elasticsearch luego reasignará los fragmentos de forma normal. Esto puede ser lento; considere aumentar los indices.recovery.max_bytes_per_sec y cluster.routing.allocation.node_concurrent_recoveries para acelerarlo.

Si sigues teniendo problemas, probablemente haya algún otro error, así que busca en los registros de Elasticsearch los errores. Si ve EsRejectedExecutionException sus grupos de subprocesos pueden ser demasiado pequeños .

Finalmente, puede reasignar explícitamente un fragmento a un nodo con la API de redireccionamiento .

# Suppose shard 4 of index "my-index" is unassigned, so you want to
# assign it to node search03:
curl -XPOST ''localhost:9200/_cluster/reroute'' -d ''{
    "commands": [{
        "allocate": {
            "index": "my-index",
            "shard": 4,
            "node": "search03",
            "allow_primary": 1
        }
    }]
}''

Answer 2

Elasticsearch asigna automáticamente fragmentos si la configuración siguiente está establecida en todos. Esta configuración se puede establecer usando una API de reposo también cluster.routing.allocation.enable: all

Si incluso después de la aplicación de la configuración siguiente, falla en asignar los fragmentos automáticamente, entonces usted debe forzar la asignación de los fragmentos por su cuenta. ES enlace oficial para esto

He escrito una secuencia de comandos para forzar la asignación de todos los fragmentos no asignados en el clúster.

below array contiene una lista de nodos entre los que desea equilibrar los fragmentos no asignados

#!/bin/bash
array=( node1 node2 node3 )
node_counter=0
length=${#array[@]}
IFS=$''/n''
for line in $(curl -s ''http://127.0.0.1:9200/_cat/shards''|  fgrep UNASSIGNED); do
    INDEX=$(echo $line | (awk ''{print $1}''))
    SHARD=$(echo $line | (awk ''{print $2}''))
    NODE=${array[$node_counter]}
    echo $NODE
    curl -XPOST ''http://127.0.0.1:9200/_cluster/reroute'' -d ''{
        "commands": [
        {
            "allocate": {
                "index": "''$INDEX''",
                "shard": ''$SHARD'',
                "node": "''$NODE''",
                "allow_primary": true
            }
        }
        ]
    }''
    node_counter=$(((node_counter)%length +1))
done

Answer 3

En mi caso, cuando creo un índice nuevo, el valor predeterminado number_of_replicas se establece en 1. Y el número de nodos en mi clúster era solo uno, por lo que no había ningún nodo adicional para crear la réplica, por lo que el estado de salud se estaba volviendo amarillo. Entonces, cuando creé el índice con la propiedad de configuraciones y configuré el número de respuestas como 0. Entonces funcionó bien. Espero que esto ayude.

PUT /customer
{
    "settings": {
        "number_of_replicas": 0
    }
}

Answer 4

En mi caso, se alcanzó el límite superior del espacio en el disco duro.

Mira este artículo: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html

Básicamente, corrí:

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "90%",
    "cluster.routing.allocation.disk.watermark.high": "95%",
    "cluster.info.update.interval": "1m"
  }
}

Para que se asigne si se utiliza <90% de espacio en el disco duro y mueva un fragmento a otra máquina en el clúster si se usa> 95% de espacio en el disco duro; y comprueba cada 1 minuto.

Answer 5

En mi caso, un antiguo nodo con acciones antiguas se unía al clúster, por lo que tuvimos que cerrar el nodo anterior y eliminar los índices con fragmentos no asignados.

Answer 6

Estaba teniendo este problema también, y encontré una manera fácil de resolverlo.

• Obtener el índice de fragmentos sin asignar

  $ curl -XGET http://172.16.4.140:9200/_cat/shards

• Instale las herramientas de conservador y úselo para eliminar el índice

  $ curator --host 172.16.4.140 delete indices --older-than 1 /
         --timestring ''%Y.%m.%d'' --time-unit days --prefix logstash

  NOTA: En mi caso, el índice es logstash del día 2016-04-21

• Luego revisa los fragmentos nuevamente, ¡todos los fragmentos sin asignar desaparecen!

Answer 7

Este pequeño script bash reasignará fuerza bruta, puede perder datos.

NODE="YOUR NODE NAME"
IFS=$''/n''
for line in $(curl -s ''localhost:9200/_cat/shards'' | fgrep UNASSIGNED); do
  INDEX=$(echo $line | (awk ''{print $1}''))
  SHARD=$(echo $line | (awk ''{print $2}''))

  curl -XPOST ''localhost:9200/_cluster/reroute'' -d ''{
     "commands": [
        {
            "allocate": {
                "index": "''$INDEX''",
                "shard": ''$SHARD'',
                "node": "''$NODE''",
                "allow_primary": true
          }
        }
    ]
  }''
done

Answer 8

Hoy me he quedado con el mismo problema de asignación de fragmentos. El guión que ha propuesto en su respuesta no me funcionó, así que lo modifiqué un poco y finalmente funcionó:

#!/usr/bin/env bash

# The script performs force relocation of all unassigned shards, 
# of all indices to a specified node (NODE variable)

ES_HOST="<elasticsearch host>"
NODE="<node name>"

curl ${ES_HOST}:9200/_cat/shards > shards
grep "UNASSIGNED" shards > unassigned_shards

while read LINE; do
  IFS=" " read -r -a ARRAY <<< "$LINE"
  INDEX=${ARRAY[0]}
  SHARD=${ARRAY[1]}

  echo "Relocating:"
  echo "Index: ${INDEX}"
  echo "Shard: ${SHARD}"
  echo "To node: ${NODE}"

  curl -s -XPOST "${ES_HOST}:9200/_cluster/reroute" -d "{
    /"commands/": [
       {
         /"allocate/": {
           /"index/": /"${INDEX}/",
           /"shard/": ${SHARD},
           /"node/": /"${NODE}/",
           /"allow_primary/": true
         }
       }
     ]
  }"; echo
  echo "------------------------------"
done <unassigned_shards

rm shards
rm unassigned_shards

exit 0

Ahora, no soy un gurú de Bash, pero el guión realmente funcionó para mi caso. Tenga en cuenta que necesitará especificar los valores apropiados para las variables "ES_HOST" y "NODE".

Answer 9

Intenté eliminar fragmentos sin asignar o asignarlos manualmente a un nodo de datos particular. No funcionó porque los fragmentos no asignados seguían apareciendo y el estado de salud era "rojo" una y otra vez. Entonces noté que uno de los nodos de datos estaba atascado en el estado de "reinicio". Reduzco el número de nodos de datos, lo maté. El problema ya no es reproducible

Answer 10

Lo único que funcionó para mí fue cambiar number_of_replicas (tenía 2 réplicas, así que lo cambié a 1 y luego volví a cambiar a 2).

Primero:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 1
     }
}

Entonces:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 2
     }
}

(Ya lo asentí en esta pregunta )

Answer 11

Me encontré con exactamente el mismo problema. Esto se puede evitar estableciendo temporalmente la asignación de fragmento en falso antes de reiniciar elasticsearch, pero esto no soluciona los fragmentos no asignados si ya están allí.

En mi caso, fue causado por la falta de espacio libre en el disco en el nodo de datos. Los fragmentos sin asignar permanecen en el nodo de datos después del reinicio, pero no son reconocidos por el maestro.

Simplemente limpiando 1 de los nodos del disco se inició el proceso de replicación. Este es un proceso bastante lento porque todos los datos deben ser copiados de 1 nodo de datos a otro.

Answer 12

OK, lo he resuelto con un poco de ayuda de ES. Emita el siguiente comando a la API en todos los nodos (o los nodos que cree que son la causa del problema):

curl -XPUT ''localhost:9200/<index>/_settings'' /
    -d ''{"index.routing.allocation.disable_allocation": false}''

donde <index> es el índice que usted cree que es el culpable. Si no tiene idea, simplemente ejecute esto en todos los nodos:

curl -XPUT ''localhost:9200/_settings'' /
    -d ''{"index.routing.allocation.disable_allocation": false}''

También agregué esta línea a mi configuración de yml y desde entonces, cualquier reinicio del servidor / servicio ha estado libre de problemas. Los fragmentos se reasignaron inmediatamente.

FWIW, para responder a una pregunta frecuente, establezca MAX_HEAP_SIZE en 30G a menos que su máquina tenga menos de 60G de RAM, en cuyo caso configúrela a la mitad de la memoria disponible.

Answer 13

Otra posible razón para los fragmentos no asignados es que su clúster ejecuta más de una versión del binario de Elasticsearch.

La replicación de fragmentos desde la versión más reciente a las versiones anteriores no funcionará

Esta puede ser la causa raíz de los fragmentos no asignados.

Elastic Documentation - Rolling Upgrade Process

Answer 14

Para mí, esto se resolvió ejecutando esto desde la consola de desarrollo: "POST / _cluster / reroute? Retry_failed"

.....

Empecé mirando la lista de índices para ver qué índices eran rojos y luego corrí

"obtener /_cat/shards?h=[INDEXNAME],shard,prirep,state,unassigned.reason"

y vio que tenía fragmentos atrapados en el estado ALLOCATION_FAILED, por lo que ejecutar el reintento anterior provocó que volvieran a intentar la asignación.

Answer 15

Podría ayudar, pero tuve este problema al intentar ejecutar ES en modo incrustado. La reparación era para asegurarse de que el Nodo tuviera un conjunto local (verdadero).

Answer 16

Probé varias de las sugerencias anteriores y desafortunadamente ninguna funcionó. Tenemos un índice "Log" en nuestro entorno más bajo donde las aplicaciones escriben sus errores. Es un clúster de nodo único. Lo que me solucionó fue comprobar el archivo de configuración YML para el nodo y ver que todavía tenía la configuración predeterminada "gateway.expected_nodes: 2". Esto estaba anulando cualquier otra configuración que teníamos. Siempre que creáramos un índice en este nodo, trataríamos de esparcir 3 de 5 fragmentos al segundo nodo fantasma. Por lo tanto, estos aparecerían como no asignados y nunca podrían moverse al primer y único nodo.

La solución era editar la configuración, cambiando la configuración "gateway.expected_nodes" a 1, por lo que dejaría de buscar su hermano nunca encontrado en el clúster y reiniciar la instancia de servicio Elastic. Además, tuve que eliminar el índice y crear uno nuevo. Después de crear el índice, todos los fragmentos aparecieron en el primer y único nodo, y ninguno fue desasignado.

# Set how many nodes are expected in this cluster. Once these N nodes
# are up (and recover_after_nodes is met), begin recovery process immediately
# (without waiting for recover_after_time to expire):
#
# gateway.expected_nodes: 2
gateway.expected_nodes: 1

Answer 17

Tal vez ayuda a alguien, pero tuve el mismo problema y fue debido a la falta de espacio de almacenamiento causado por un tronco que se está volviendo demasiado grande.

Espero que ayude a alguien! :)

Answer 18

También me encuentro con esta situación y finalmente lo solucioné.

En primer lugar, describiré mi situación. Tengo dos nodos en el clúster ElasticSearch, pueden encontrarse entre sí, pero cuando creé un índice con la configuración "number_of_replicas": 2 , "number_of_shards": 5, ES muestra señal amarilla y unassigned_shards es 5.

El problema ocurre porque el valor de number_of_replicas , cuando establezco su valor con 1 , todo está bien.

Answer 19

Tuve el mismo problema, pero la causa principal fue la diferencia en los números de versión (1.4.2 en dos nodos (con problemas) y 1.4.4 en dos nodos (ok)). La primera y la segunda respuesta (estableciendo "index.routing.allocation.disable_allocation" en falso y estableciendo "cluster.routing.allocation.enable" en "all") no funcionó.

Sin embargo, la respuesta de @Wilfred Hughes (estableciendo "cluster.routing.allocation.enable" en "all" usando transient) me dio un error con la siguiente declaración:

[NO (versión del nodo de destino [1.4.2] es anterior a la versión del nodo de origen [1.4.4])]

Después de actualizar los nodos antiguos a 1.4.4, estos nodos comenzaron a sincronizarse con los otros nodos buenos.