# Shards or indices redistributed intelligence **URL:** \ **Category:** Elasticsearch\ **Created:** [December 26, 2012, 1:12am UTC](https://discuss.elastic.co/t/shards-or-indices-redistributed-intelligence/10171 "2012-12-26T01:12:57Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dean\_2](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@dean\_2](https://discuss.elastic.co/u/dean_2)\ **Post date:** [December 26, 2012, 1:12am UTC](https://discuss.elastic.co/t/shards-or-indices-redistributed-intelligence/10171/1 "2012-12-26T01:12:57Z")
There are 3 nodes(physical server) in a ES cluster. Let's say they are NODE\_1, NODE\_2 and NODE\_3. The index setting as below. index.number\_of\_replicas : 0 index.number\_of\_shards : 5 Now I find that for a particular index, 3 of the shards are stored on NODE\_2, 1 of the shards is stored on NODE\_1 and the last shard is stored on NODE\_3. The problem is that there is no enough disk space left on NODE\_2. So when more and more documents come to the cluster, NODE\_2 will throw IO exception because there is no enough space. But for NODE\_1 and NODE\_3, there are still much space left. My question is as below. 1. Is there option to let the shards distributed evenly on the nodes? For example, if there are 3 nodes and the number of shards is 6, then there will be 2 shards on every node. 2. Is ES intelligent enough to reprocess the failed documents. For example like above, if there is no enough space left for NODE\_2, will ES ask NODE\_1 or NODE\_3 to reindex the documents that NODE\_2 does not index? -- ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [December 26, 2012, 3:43am UTC](https://discuss.elastic.co/t/shards-or-indices-redistributed-intelligence/10171/2 "2012-12-26T03:43:38Z")
Allocation is determined by the default allocator: EvenShardsCountAllocator. Do you have other indices in your cluster? The allocator should allocated five shards more evenly. The default allocator will allocate shards according the total number of shards for all indices, regardless of the size of each shard. There is a plugin that will replace the default allocator with one that is disk space aware: [GitHub - sonian/elasticsearch-equilibrium](https://github.com/sonian/elasticsearch-equilibrium) Never used it, so I cannot comment on it. -- Ivan On Tue, Dec 25, 2012 at 5:12 PM, Dean Zhang from China \< [elasticbetter@gmail.com](mailto:elasticbetter@gmail.com)\> wrote: > There are 3 nodes(physical server) in a ES cluster. > Let's say they are NODE\_1, NODE\_2 and NODE\_3. > > The index setting as below. > index.number\_of\_replicas : 0 > index.number\_of\_shards : 5 > > Now I find that for a particular index, > 3 of the shards are stored on NODE\_2, > 1 of the shards is stored on NODE\_1 > and the last shard is stored on NODE\_3. > > The problem is that there is no enough disk space left on NODE\_2. > So when more and more documents come to the cluster, NODE\_2 will throw IO > exception because there is no enough space. > But for NODE\_1 and NODE\_3, there are still much space left. > > My question is as below. > > 1. Is there option to let the shards distributed evenly on the nodes? > For example, if there are 3 nodes and the number of shards is 6, then > there will be 2 shards on every node. > 2. Is ES intelligent enough to reprocess the failed documents. > For example like above, if there is no enough space left for NODE\_2, > will ES ask NODE\_1 or NODE\_3 to reindex the documents that NODE\_2 does not > index? > > -- -- ---
**Author:** ![dean\_2](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@dean\_2](https://discuss.elastic.co/u/dean_2)\ **Post date:** [January 3, 2013, 3:13am UTC](https://discuss.elastic.co/t/shards-or-indices-redistributed-intelligence/10171/3 "2013-01-03T03:13:51Z")
Thanks Ivan. You are great help. I'm looking into this plugin. 在 2012年12月26日星期三UTC+8上午11时43分38秒，Ivan Brusic写道： > Allocation is determined by the default > allocator: EvenShardsCountAllocator. Do you have other indices in your > cluster? The allocator should allocated five shards more evenly. The > default allocator will allocate shards according the total number of shards > for all indices, regardless of the size of each shard. > > There is a plugin that will replace the default allocator with one that is > disk space aware: [GitHub - sonian/elasticsearch-equilibrium](https://github.com/sonian/elasticsearch-equilibrium) > > Never used it, so I cannot comment on it. > > -- > Ivan > > On Tue, Dec 25, 2012 at 5:12 PM, Dean Zhang from China \< > [elasti...@gmail.com](mailto:elasti...@gmail.com) \\> wrote: > > > There are 3 nodes(physical server) in a ES cluster. > > Let's say they are NODE\_1, NODE\_2 and NODE\_3. > > > > The index setting as below. > > index.number\_of\_replicas : 0 > > index.number\_of\_shards : 5 > > > > Now I find that for a particular index, > > 3 of the shards are stored on NODE\_2, > > 1 of the shards is stored on NODE\_1 > > and the last shard is stored on NODE\_3. > > > > The problem is that there is no enough disk space left on NODE\_2. > > So when more and more documents come to the cluster, NODE\_2 will throw IO > > exception because there is no enough space. > > But for NODE\_1 and NODE\_3, there are still much space left. > > > > My question is as below. > > > > 1. Is there option to let the shards distributed evenly on the nodes? > > For example, if there are 3 nodes and the number of shards is 6, > > then there will be 2 shards on every node. > > 2. Is ES intelligent enough to reprocess the failed documents. > > For example like above, if there is no enough space left for NODE\_2, > > will ES ask NODE\_1 or NODE\_3 to reindex the documents that NODE\_2 does not > > index? > > > > -- -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:57am UTC](https://discuss.elastic.co/t/shards-or-indices-redistributed-intelligence/10171/4 "2017-07-06T02:57:58Z")