Rolling restart / rolling upgrade (nœud par nœud, sans déplacements de shards inutiles)

Commande

# 1) Disable replica allocation (only primaries are allocated):
PUT _cluster/settings
{
  "persistent": { "cluster.routing.allocation.enable": "primaries" }
}
# 2) Optional: stop indexing and flush to speed up recovery:
POST _flush
# 3) Stop one node, do the maintenance, start it; verify it joined:
GET _cat/nodes?v&h=name,version,node.role,master,heap.percent
# 4) Re-enable allocation:
PUT _cluster/settings
{
  "persistent": { "cluster.routing.allocation.enable": null }
}
# 5) Wait for green before moving to the next node:
GET _cluster/health?wait_for_status=green&timeout=10m

Ce que fait la commande

Donne l'ordre de redémarrage ou de mise à niveau des nœuds un par un tout en empêchant que les réplicas soient recopiés vers d'autres nœuds quand un nœud est arrêté ; au retour du nœud, les shards se rétablissent rapidement depuis la copie locale.

Quand l'utiliser

Lors du redémarrage séquentiel des nœuds pour un correctif OS, un changement JVM/heap, une modification d'elasticsearch.yml ou une mise à niveau de version mineure/majeure.

Attention

Ne passez pas au nœud suivant sans attendre le green ; avec deux nœuds arrêtés en même temps, toutes les copies d'un shard peuvent avoir disparu. Redémarrez les nœuds master-eligible en dernier et un par un ; si la majorité est perdue, le cluster ne peut pas élire de master. Si vous oubliez de réactiver allocation.enable, les réplicas restent non assignés. Lors d'une mise à niveau, les nœuds data sont mis à niveau en premier (frozen/cold d'abord, hot en dernier), puis les masters.