Triage-Ablauf für roten/gelben Cluster (welcher Index, welcher Shard, warum)

Befehl

GET _cluster/health?filter_path=status,unassigned_shards,initializing_shards,delayed_unassigned_shards,number_of_pending_tasks
GET _health_report?verbose=false
GET _cat/indices?v&health=red&h=health,index,pri,rep,docs.count,store.size
GET _cat/indices?v&health=yellow&h=health,index,pri,rep
GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,unassigned.for,node&s=state
# Without a body, the call explains the first unassigned shard:
GET _cluster/allocation/explain

Was es tut

Gibt einen geordneten Triage-Ablauf vor: vom Cluster-Status zu den problematischen Indizes, dann zu den nicht zugewiesenen Shards und dem Grund, warum sie nicht zugewiesen werden (unassigned.reason, allocation explain); _health_report fasst zusammen, welcher Indikator (Platte, Shard-Verfügbarkeit, Master) nicht gesund ist.

Wann einsetzen

Als erste Reaktion, wenn der Cluster rot oder gelb wird.

Vorsicht

Rot: Mindestens ein Primary Shard ist nicht zugewiesen; Schreibzugriffe auf diesen Index und Suchen, die diesen Shard treffen, schlagen fehl. Gelb: Alle Primaries sind vorhanden, aber Replicas fehlen; die Daten sind erreichbar, aber es gibt keine Redundanz. Auf einem Single-Node-Cluster bleiben Indizes mit replicas > 0 dauerhaft gelb (Entscheidung same_shard). Hat ein Knoten den Cluster kürzlich verlassen, werden delayed_unassigned_shards absichtlich zurückgehalten, bis index.unassigned.node_left.delayed_timeout (Standard 1m) abläuft.