# Cluster holds an odd number of shards

**URL:** <https://discuss.elastic.co/t/cluster-holds-an-odd-number-of-shards/385986>\
**Category:** Elasticsearch\
**Created:** [April 21, 2026, 8:39pm UTC](https://discuss.elastic.co/t/cluster-holds-an-odd-number-of-shards/385986 "2026-04-21T20:39:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![stefws](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stefws/32/6442_2.png) [@stefws](https://discuss.elastic.co/u/stefws)\
**Post date:** [April 21, 2026, 8:39pm UTC](https://discuss.elastic.co/t/cluster-holds-an-odd-number-of-shards/385986/1 "2026-04-21T20:39:27Z")

</div>

Hi

Wondering about the number of shards in our v.8.19.9 cluster been odd like this when all shards ought to have exactly 1 replica:

```auto
$ eshealth
{
  "cluster_name" : "pjp-es-epj",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 15,
  "number_of_data_nodes" : 8,
  "active_primary_shards" : 457,
  "active_shards" : 915,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "unassigned_primary_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

```

Would have expected active shards = 914, as every index seems to have as expected exactly 1 replica only, ie this returns no matches:

```auto
$ esapi -g '_cat/indices?h=index,rep' | grep -v ' 1$'
$ esapi -g '_cat/indices?h=index,rep' | grep -c ' 1$'
284

```

Wondering where that extra shard hides, hints appreciated, TIA.

Our monitoring cluster seems to show long-living Shards Activity now and then, like the activity never finishes, eg:

 ![Screenshot 2026-04-21 at 22.26.01](https://us1.discourse-cdn.com/elastic/original/3X/6/8/68c8e6fc453448e63c5c461dd7401818dd7580be.png)

Only this shard seems fine ImHO:

 ![Screenshot 2026-04-21 at 22.26.44](https://us1.discourse-cdn.com/elastic/original/3X/2/a/2a2cc1436395243679876663dee47ffaba1d40e7.png)

Also wondering why hot/warm data nodes' shard counts doesn't seem perfectly balanced:

 ![Screenshot 2026-04-21 at 22.35.40](https://us1.discourse-cdn.com/elastic/original/3X/c/9/c9d0aa8aa68b05eb40195e8683f9d0eb64a443b3.png)

---

<div class="post-metadata">

**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\
**Post date:** [April 21, 2026, 11:28pm UTC](https://discuss.elastic.co/t/cluster-holds-an-odd-number-of-shards/385986/2 "2026-04-21T23:28:10Z")

</div>

> [@stefws](#):
>
> Would have expected active shards = 914, as every index seems to have as expected exactly 1 replica only, ie this returns no matches:

Have you used the `_cat/shards` endpoint? Some internal indices may have auto-expand replicas so I would not expect evertying to have exactly 1 replica.

Also, you seem to be using shrink on your lifecycle, so this number may be related to a shrink task running.

> [@stefws](#):
>
> Our monitoring cluster seems to show long-living Shards Activity now and then

Show where? Is this from AutoOps? I've had some false positives with AutoOps.

> [@stefws](#):
>
> Also wondering why hot/warm data nodes' shard counts doesn't seem perfectly balanced

On 8.6 the heuristic was changed to consider other things like disk space and also write load depending on the license, so I'm not sure if we should expect it to be equal anymore, even though this is what is mentioned on the documentation.

On my cluster I also do not have an equal number of shards, but they are pretty close.

---

<div class="post-metadata">

**Author:** ![stefws](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stefws/32/6442_2.png) [@stefws](https://discuss.elastic.co/u/stefws)\
**Post date:** [April 22, 2026, 7:29am UTC](https://discuss.elastic.co/t/cluster-holds-an-odd-number-of-shards/385986/3 "2026-04-22T07:29:39Z")

</div>

Ah found a default APM index: .apm-source-map with 1 primary on node769 and 2 replicas on node765+node770 🙂

```auto
$ esapi -g '_cat/shards?h=index,shard,prirep,state,node' | sort | awk '/ r /{printf " - %s",$0} / p /{printf "\n%s",$0}'

.apm-agent-configuration 0 p STARTED node771 - .apm-agent-configuration 0 r STARTED node769
.apm-custom-link 0 p STARTED node769 - .apm-custom-link 0 r STARTED node771
.apm-source-map 0 p STARTED node769 - .apm-source-map 0 r STARTED node765 - .apm-source-map 0 r STARTED node770

```

Right, are using DC allocation routing, as we've got nodes spread across 3x DCs.

Thanks.