Shard-Größen und Shard-Anzahl prüfen (Erkennung von Oversharding / übergroßen Shards)

Befehl

# Largest shards (GB):
GET _cat/shards?v&h=index,shard,prirep,state,docs,store,node&s=store:desc&bytes=gb
# Indices by primary size:
GET _cat/indices?v&h=index,pri,rep,docs.count,pri.store.size,store.size&s=pri.store.size:desc&bytes=gb
# Shard count and disk per node:
GET _cat/allocation?v&h=node,shards,disk.indices,disk.percent&s=shards:desc
GET _cluster/stats?filter_path=indices.shards.total,indices.shards.primaries,nodes.count.data
GET _cluster/settings?include_defaults=true&filter_path=*.cluster.max_shards_per_node

Was es tut

Listet die größten Shards, Primary-Größen der Indizes, Shard-Anzahl pro Knoten, Gesamtzahl der Shards und das Limit cluster.max_shards_per_node.

Wann einsetzen

Bei der Kapazitätsplanung, wenn Recovery-Zeiten wachsen oder der Heap-Druck steigt, und beim Fehler 'this action would add [x] shards, but this cluster currently has [y]/[z] maximum normal shards open'.

Vorsicht

Viele sehr kleine Shards (Oversharding) belasten Master und Heap; sehr große Shards dehnen Recovery und Rebalancing auf Stunden aus. Die Anzahl der Primary Shards lässt sich nach dem Anlegen des Index nicht ändern; zur Korrektur sind Shrink, Split oder Reindex nötig. Das Anheben von max_shards_per_node hebt das Limit auf, löst aber das Problem nicht.