Problemas de Asignación de Shards en Elasticsearch: Causas y Soluciones

Los problemas de asignación de shards en Elasticsearch generalmente se manifiestan como salud del clúster amarilla o roja. Amarillo significa que sus shards primarios están asignados pero al menos una réplica no lo está. Rojo significa que al menos un shard primario no está asignado, por lo que algunos datos pueden no estar disponibles hasta que los recupere.

Esta guía le muestra cómo encontrar el bloqueador de asignación, leer la salida de la API de Explicación de Asignación y elegir la solución menos riesgosa. El objetivo es restaurar la asignación sin empeorar la pérdida de datos.

Comprensión de los Estados de los Shards y la Salud del Clúster

Los shards son la unidad que Elasticsearch coloca en los nodos de datos. Pueden existir en varios estados:

• STARTED: El shard está activo y sirviendo solicitudes.
• RELOCATING: El shard se está moviendo de un nodo a otro.
• INITIALIZING: El shard se está creando o recuperando.
• UNASSIGNED: El shard existe en los metadatos del clúster pero no está asignado a un nodo.

La salud del clúster sigue esos estados de shard:

• Green: Todos los shards primarios y réplica están asignados.
• Yellow: Todos los shards primarios están asignados, pero una o más réplicas no están asignadas.
• Red: Uno o más shards primarios no están asignados. Las búsquedas pueden devolver resultados parciales o fallar para los índices afectados, y las escrituras en esos índices pueden fallar.

Causas Comunes de Fallos en la Asignación de Shards

Elasticsearch utiliza decisores de asignación antes de colocar un shard. Una sola decisión NO puede mantener un shard sin asignar.

Límites de Agua del Disco

La presión del disco es una de las causas más comunes. Elasticsearch utiliza límites de agua del disco para evitar llenar un nodo. Una vez que un nodo cruza el límite bajo o alto, las decisiones de asignación se vuelven más restrictivas. En la etapa de inundación, Elasticsearch puede agregar un bloque de solo lectura a los índices afectados para proteger el nodo de quedarse sin disco.

Configuración	Valor Predeterminado Común	Efecto
cluster.routing.allocation.disk.watermark.low	85%	Evita asignar shards adicionales a nodos por encima de este umbral.
cluster.routing.allocation.disk.watermark.high	90%	Intenta mover shards fuera y evita colocar shards en el nodo.
cluster.routing.allocation.disk.watermark.flood_stage	95%	Puede bloquear escrituras en los índices afectados.

Confirme la configuración real de su clúster antes de cambiar algo:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Luego verifique el uso del disco del nodo:

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total,shards

Libere espacio, agregue disco, agregue nodos de datos, elimine índices antiguos o reduzca la presión de réplicas. Si se estableció un bloque de etapa de inundación, elimínelo solo después de solucionar la presión del disco:

PUT /my_index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Roles de Nodo y Filtros de Asignación

Los shards de índice se asignan solo a nodos con un rol de datos y filtros de asignación coincidentes. Si utiliza atributos de nodo para niveles hot/warm, racks, zonas o tipos de almacenamiento, un error tipográfico puede dejar shards varados.

Por ejemplo, un índice con index.routing.allocation.require.box_type: high_io solo se asignará en nodos configurados con node.attr.box_type: high_io.

Verifique los filtros de índice y los atributos del nodo:

GET /my_index/_settings?filter_path=*.settings.index.routing.allocation
GET /_cat/nodeattrs?v
GET /_cat/nodes?v&h=name,roles,disk.used_percent

Corrija la configuración del índice o agregue un nodo de datos elegible. No elimine la conciencia de asignación casualmente en clústeres multizona; puede colocar todas las copias de un shard en el mismo dominio de falla.

Shards Primarios Faltantes

Si un shard primario no está asignado, el nodo que contenía el primario activo puede haber desaparecido, el índice puede haber sido restaurado recientemente, o las reglas de asignación pueden estar bloqueando todos los nodos elegibles. No asuma que los datos se perdieron hasta que la API de Explicación de Asignación le diga por qué Elasticsearch no puede asignar el shard.

Escenarios comunes incluyen:

• Un nodo que contenía la única copia primaria buena se bloqueó.
• Los filtros de asignación excluyen todos los nodos de datos que podrían alojar el primario.
• Una restauración de instantánea o creación de índice está esperando nodos elegibles.
• Existe una copia de shard obsoleta, pero Elasticsearch no la promoverá sin la aceptación explícita de pérdida de datos.

Primero intente recuperar el nodo faltante, restaurar una instantánea o solucionar el bloqueador de asignación. Use la asignación primaria forzada solo cuando comprenda qué copia está obsoleta o cuando haya aceptado la pérdida de datos para ese shard.

Límites de Shards

Los límites de shards por nodo también pueden bloquear la asignación. Las configuraciones comunes incluyen index.routing.allocation.total_shards_per_node y cluster.routing.allocation.total_shards_per_node.

Verifique esos límites:

GET /_cluster/settings?include_defaults=true&filter_path=**.total_shards_per_node
GET /my_index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node

Agregue nodos, reduzca el número de réplicas, consolide índices pequeños o aumente cautelosamente el límite relevante. Demasiados shards por nodo pueden aumentar la presión del heap y ralentizar las operaciones de estado del clúster.

Diagnóstico con la API de Explicación de Asignación

La API de Explicación de Asignación es la mejor herramienta para responder "¿por qué no se está asignando este shard?"

GET /_cluster/allocation/explain?pretty
{
  "index": "my_data",
  "shard": 0,
  "primary": true
}

Para permitir que Elasticsearch elija un shard actualmente no asignado, llame a la API sin cuerpo:

GET /_cluster/allocation/explain?pretty

Lea estos campos primero:

• can_allocate: La respuesta de alto nivel.
• allocate_explanation: El resumen en lenguaje sencillo.
• node_allocation_decisions: Decisiones por nodo.
• deciders: La regla exacta que devolvió NO o THROTTLE.

Una decisión NO es el bloqueador. Una decisión THROTTLE generalmente significa que Elasticsearch puede asignar el shard pero está limitando el trabajo de recuperación concurrente.

Secuencia Segura de Solución de Problemas

Comience de manera amplia, luego reduzca.

1. Verifique la Salud del Clúster y los Shards No Asignados

GET /_cluster/health?pretty
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node

Mire unassigned.reason. Valores como NODE_LEFT, INDEX_CREATED, CLUSTER_RECOVERED o ALLOCATION_FAILED le indican dónde buscar a continuación.

2. Verifique el Disco y la Elegibilidad del Nodo

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total
GET /_cat/nodes?v&h=name,roles,heap.percent,ram.percent,cpu,disk.used_percent

Si los nodos están cerca del límite de agua alto, solucione la presión del disco antes de cambiar la configuración de asignación.

3. Ejecute la Explicación de Asignación

Use el índice afectado, el número de shard y el indicador de primario/réplica. La salida debe nombrar la configuración, la condición del nodo o el decisor que bloquea la asignación.

4. Evite Reenrutamientos Arriesgados Hasta Que Conozca la Causa

Los comandos de reenrutamiento manual son para casos de recuperación específicos. No son una solución general para la presión del disco, filtros incorrectos o demasiadas réplicas.

Si una copia primaria obsoleta es la única ruta de recuperación práctica, el comando se ve así:

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "index_name",
        "shard": 0,
        "node": "node_name_with_stale_copy",
        "accept_data_loss": true
      }
    }
  ]
}

accept_data_loss: true se requiere por una razón. Úselo solo después de haber verificado las instantáneas, intentado recuperar el nodo faltante y confirmado qué nodo tiene la copia obsoleta.

5. Maneje la Salud Amarilla por Separado

Si solo las réplicas no están asignadas, el clúster aún puede servir datos primarios. Primero solucione la restricción de recursos subyacente. Agregar un nodo de datos, liberar disco o corregir filtros de asignación generalmente permite que Elasticsearch asigne réplicas automáticamente.

Si debe ejecutar temporalmente sin réplicas, reduzca el número de réplicas para el índice afectado:

PUT /my_index/_settings
{
  "index.number_of_replicas": 0
}

Esto puede hacer que la salud se vuelva verde porque Elasticsearch ya no espera copias de réplica para ese índice. También reduce la disponibilidad, así que vuelva a establecer las réplicas al valor deseado después de agregar capacidad o solucionar la asignación.

Prevención de Problemas de Asignación

• Alerte antes de que los nodos crucen el límite de agua alto del disco.
• Mantenga suficientes nodos de datos disponibles para su número de réplicas y reglas de conciencia de asignación.
• Use recuentos de shards que se ajusten a su heap, volumen de datos y objetivos de recuperación.
• Revise las plantillas de índice para que los nuevos índices no hereden recuentos de réplicas o filtros de asignación incorrectos.
• Pruebe el reemplazo de nodos y los pasos de restauración de instantáneas antes de un incidente.

Conclusión

Su camino más seguro es simple: identifique el shard no asignado, ejecute la Explicación de Asignación, corrija el decisor que dice NO y evite la asignación forzada a menos que haya aceptado la compensación de pérdida de datos.