Cluster Elasticsearch red/yellow et shards non assignés

Symptôme

_cluster/health 'red' ou 'yellow' ; shards non assignés ; lectures/écritures restreintes ou données inaccessibles.

1. Couleur et cause

yellow = des shards réplicas ne sont pas assignés (les données sont présentes, la durabilité est réduite). red = au moins un shard PRIMAIRE manque (ces données sont inaccessibles). Déterminez d'abord lequel et pourquoi.

Elasticsearch

GET _cluster/health?level=indices
GET _cluster/allocation/explain

2. Listez les shards non assignés et leur raison

La colonne unassigned.reason donne la cause profonde (NODE_LEFT, ALLOCATION_FAILED, DISK, etc.).

Elasticsearch

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason&s=state

3. Traitez les causes courantes

1) Disk watermark → au-delà de low, le nœud ne reçoit plus de nouveaux shards ; à flood_stage, les index passent en lecture seule. 2) Un nœud est tombé / est parti. 3) L'allocation a été laissée désactivée. 4) Nombre de réplicas > nombre de nœuds éligibles.

4. Corrigez

Débloquez selon la cause en jeu.

Elasticsearch

# If disk space was freed, remove the read-only block (7.4+ also lifts it automatically once below the high watermark):
PUT _all/_settings {"index.blocks.read_only_allow_delete": null}
# If allocation was left restricted, return it to the default (all):
PUT _cluster/settings {"persistent":{"cluster.routing.allocation.enable":null}}
# Retry failed allocations:
POST _cluster/reroute?retry_failed=true

5. Si c'est toujours red et que le primaire est réellement perdu

Restaurez l'index concerné depuis un snapshot ou réindexez-le à partir des données source (_reindex). Définitif : alertes sur le disk watermark, nombre de réplicas approprié (≥1) et surveillance de la santé des nœuds.