Rolling Restart / Rolling Upgrade (Knoten für Knoten, ohne unnötige Shard-Verschiebungen)

Befehl

# 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

Was es tut

Gibt die Reihenfolge vor, in der Knoten einzeln neu gestartet oder aktualisiert werden, und verhindert dabei, dass Replicas bei einem ausgefallenen Knoten auf andere Knoten neu kopiert werden; kehrt der Knoten zurück, erholen sich die Shards schnell aus der lokalen Kopie.

Wann einsetzen

Beim aufeinanderfolgenden Neustart von Knoten für einen OS-Patch, eine JVM-/Heap-Änderung, eine Änderung an elasticsearch.yml oder ein Minor-/Major-Upgrade.

Vorsicht

Gehe nicht zum nächsten Knoten über, ohne auf green zu warten; sind zwei Knoten gleichzeitig ausgefallen, können alle Kopien eines Shards weg sein. Starte master-fähige Knoten zuletzt und einzeln neu; geht die Mehrheit verloren, kann der Cluster keinen Master wählen. Vergisst du, allocation.enable wieder zu aktivieren, bleiben Replicas unassigned. Bei einem Upgrade werden zuerst die Datenknoten aktualisiert (frozen/cold zuerst, hot zuletzt), dann die Master.