DBAtlas · Atlas de operaciones de bases de datos

Auditar el tamaño y el número de shards (detección de oversharding / shards demasiado grandes)

ElasticsearchMantenimiento

Comando

# 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

Qué hace

Lista los shards más grandes, el tamaño primario de los índices, el número de shards por nodo, el número total de shards y el límite cluster.max_shards_per_node.

Cuándo usarlo

Durante la planificación de capacidad, cuando crecen los tiempos de recuperación o sube la presión del heap, y ante el error 'this action would add [x] shards, but this cluster currently has [y]/[z] maximum normal shards open'.

Precaución

Muchos shards muy pequeños (oversharding) castigan al master y al heap; los shards muy grandes alargan la recuperación y el rebalanceo hasta horas. El número de shards primarios no se puede cambiar tras crear el índice; para corregirlo hace falta shrink, split o reindex. Subir max_shards_per_node elimina el límite pero no resuelve el problema.

Abrir en DBAtlas →

Relacionado