# No failover if number\_of\_replicas exceeds number of nodes?
**URL:** https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514
**Category:** Elasticsearch
**Created:** [January 7, 2015, 3:08am UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514 "2015-01-07T03:08:11Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Mathew\_D](https://discuss.elastic.co/u/Mathew_D)
#### Post date: [January 7, 2015, 3:08am UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/1 "2015-01-07T03:08:11Z")
Hi all,
I've encountered some unexpected behaviour during my DR testing which I'm
trying to explain.
I have a 3-node geographically-separated cluster with the following
settings:
- index.number\_of\_shards=5
- index.number\_of\_replicas=2
- discovery.zen.minimum\_master\_nodes: 2
I use number\_of\_replicas=2 for durability, so that each node will contain a
full set to data (meaning I can lose 2 of my 3 nodes without losing any
data).
However I am finding that if I shut down 2 nodes, after adjusting
minimum\_master\_nodes on the remaining node to 1 and restarting that node,
the cluster stays yellow with all shards unassigned. They remain in the
unassigned state until I manually reduce number\_of\_replicas to down 1 or 0.
Once number\_of\_replicas \<= number of nodes, the shards reassign and the
cluster goes green. Just wondering if this behaviour is as designed?
Regards,
Mat
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [January 7, 2015, 3:58am UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/2 "2015-01-07T03:58:27Z")
It's not recommended to run an Elasticsearch cluster across geographically
dispersed locations.
You cannot assign both primaries and replicas to a single node, it defeats
the purpose! So it's as design.
On 7 January 2015 at 14:08, Mathew D [mathew.degerholm@gmail.com](mailto:mathew.degerholm@gmail.com) wrote:
> Hi all,
>
> I've encountered some unexpected behaviour during my DR testing which I'm
> trying to explain.
>
> I have a 3-node geographically-separated cluster with the following
> settings:
>
> - index.number\_of\_shards=5
> - index.number\_of\_replicas=2
> - discovery.zen.minimum\_master\_nodes: 2
>
> I use number\_of\_replicas=2 for durability, so that each node will contain
> a full set to data (meaning I can lose 2 of my 3 nodes without losing any
> data).
>
> However I am finding that if I shut down 2 nodes, after adjusting
> minimum\_master\_nodes on the remaining node to 1 and restarting that node,
> the cluster stays yellow with all shards unassigned. They remain in the
> unassigned state until I manually reduce number\_of\_replicas to down 1 or
> 0. Once number\_of\_replicas \<= number of nodes, the shards reassign and the
> cluster goes green. Just wondering if this behaviour is as designed?
>
> Regards,
> Mat
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> To view this discussion on the web visit
> [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com)
> [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm_medium=email&utm_source=footer)
> .
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X99BqEA%2BbkAF63K9OygEgU84BD-YJV7rwQ0YkXjm-VFwg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X99BqEA%2BbkAF63K9OygEgU84BD-YJV7rwQ0YkXjm-VFwg%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@Mathew\_D](https://discuss.elastic.co/u/Mathew_D)
#### Post date: [January 7, 2015, 7:52pm UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/3 "2015-01-07T19:52:51Z")
I understand there's no point assigning primaries _and_ replicas to a
single node, but in my case ES won't even allocate a primary (until I
reduce the number of replicas)
On Wednesday, January 7, 2015 4:58:58 PM UTC+13, Mark Walkom wrote:
> It's not recommended to run an Elasticsearch cluster across geographically
> dispersed locations.
>
> You cannot assign both primaries and replicas to a single node, it defeats
> the purpose! So it's as design.
>
> On 7 January 2015 at 14:08, Mathew D \<[mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) \\>
> wrote:
>
> > Hi all,
> >
> > I've encountered some unexpected behaviour during my DR testing which I'm
> > trying to explain.
> >
> > I have a 3-node geographically-separated cluster with the following
> > settings:
> >
> > - index.number\_of\_shards=5
> > - index.number\_of\_replicas=2
> > - discovery.zen.minimum\_master\_nodes: 2
> >
> > I use number\_of\_replicas=2 for durability, so that each node will contain
> > a full set to data (meaning I can lose 2 of my 3 nodes without losing any
> > data).
> >
> > However I am finding that if I shut down 2 nodes, after adjusting
> > minimum\_master\_nodes on the remaining node to 1 and restarting that node,
> > the cluster stays yellow with all shards unassigned. They remain in the
> > unassigned state until I manually reduce number\_of\_replicas to down 1 or
> > 0. Once number\_of\_replicas \<= number of nodes, the shards reassign and the
> > cluster goes green. Just wondering if this behaviour is as designed?
> >
> > Regards,
> > Mat
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \.
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com)
> > [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [January 7, 2015, 9:03pm UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/4 "2015-01-07T21:03:17Z")
A cluster cannot be yellow if any primaries are unassigned. Are you sure
it's yellow before you set replica's to 0?
On 8 January 2015 at 06:52, Mathew D [mathew.degerholm@gmail.com](mailto:mathew.degerholm@gmail.com) wrote:
> I understand there's no point assigning primaries _and_ replicas to a
> single node, but in my case ES won't even allocate a primary (until I
> reduce the number of replicas)
>
> On Wednesday, January 7, 2015 4:58:58 PM UTC+13, Mark Walkom wrote:
>
> > It's not recommended to run an Elasticsearch cluster across
> > geographically dispersed locations.
> >
> > You cannot assign both primaries and replicas to a single node, it
> > defeats the purpose! So it's as design.
> >
> > On 7 January 2015 at 14:08, Mathew D [mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) wrote:
> >
> > > Hi all,
> > >
> > > I've encountered some unexpected behaviour during my DR testing which
> > > I'm trying to explain.
> > >
> > > I have a 3-node geographically-separated cluster with the following
> > > settings:
> > >
> > > - index.number\_of\_shards=5
> > > - index.number\_of\_replicas=2
> > > - discovery.zen.minimum\_master\_nodes: 2
> > >
> > > I use number\_of\_replicas=2 for durability, so that each node will
> > > contain a full set to data (meaning I can lose 2 of my 3 nodes without
> > > losing any data).
> > >
> > > However I am finding that if I shut down 2 nodes, after adjusting
> > > minimum\_master\_nodes on the remaining node to 1 and restarting that node,
> > > the cluster stays yellow with all shards unassigned. They remain in the
> > > unassigned state until I manually reduce number\_of\_replicas to down 1 or
> > > 0. Once number\_of\_replicas \<= number of nodes, the shards reassign and the
> > > cluster goes green. Just wondering if this behaviour is as designed?
> > >
> > > Regards,
> > > Mat
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "elasticsearch" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%
> > > [40googlegroups.com](http://40googlegroups.com)
> > > [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > .
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com)
> > [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X8HPUQada0aLLGufES6PA05aMLrgHtHvvMmARwE6zFK-A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X8HPUQada0aLLGufES6PA05aMLrgHtHvvMmARwE6zFK-A%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@Mathew\_D](https://discuss.elastic.co/u/Mathew_D)
#### Post date: [January 7, 2015, 10:38pm UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/5 "2015-01-07T22:38:56Z")
Good point... actually it looks like the 'head' plugin is misreporting a
yellow status when replicas=2:
[https://lh4.googleusercontent.com/-nv6MfIzqKuk/VK2x3\_VXgsI/AAAAAAAAASI/EzZ5Ejrw4yo/s1600/cluster-status-with-2-replicas.png](https://lh4.googleusercontent.com/-nv6MfIzqKuk/VK2x3_VXgsI/AAAAAAAAASI/EzZ5Ejrw4yo/s1600/cluster-status-with-2-replicas.png)
Because when I access the \_cluster/health endpoint, a status of red is
returned:
{
"cluster\_name": "KR\_elasticsearch\_PROD",
"status": "red",
"timed\_out": false,
"number\_of\_nodes": 1,
"number\_of\_data\_nodes": 1,
"active\_primary\_shards": 0,
"active\_shards": 0,
"relocating\_shards": 0,
"initializing\_shards": 0,
"unassigned\_shards": 75
}
So you're correct that the cluster cannot be yellow with primaries
unassigned. However would still be good to know why ES would refuse to
allocate primary shards if the number of replicas exceeds the number of
nodes.
Cheers,
Mat
On Thursday, January 8, 2015 10:03:51 AM UTC+13, Mark Walkom wrote:
> A cluster cannot be yellow if any primaries are unassigned. Are you sure
> it's yellow before you set replica's to 0?
>
> On 8 January 2015 at 06:52, Mathew D \<[mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) \\>
> wrote:
>
> > I understand there's no point assigning primaries _and_ replicas to a
> > single node, but in my case ES won't even allocate a primary (until I
> > reduce the number of replicas)
> >
> > On Wednesday, January 7, 2015 4:58:58 PM UTC+13, Mark Walkom wrote:
> >
> > > It's not recommended to run an Elasticsearch cluster across
> > > geographically dispersed locations.
> > >
> > > You cannot assign both primaries and replicas to a single node, it
> > > defeats the purpose! So it's as design.
> > >
> > > On 7 January 2015 at 14:08, Mathew D [mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) wrote:
> > >
> > > > Hi all,
> > > >
> > > > I've encountered some unexpected behaviour during my DR testing which
> > > > I'm trying to explain.
> > > >
> > > > I have a 3-node geographically-separated cluster with the following
> > > > settings:
> > > >
> > > > - index.number\_of\_shards=5
> > > > - index.number\_of\_replicas=2
> > > > - discovery.zen.minimum\_master\_nodes: 2
> > > >
> > > > I use number\_of\_replicas=2 for durability, so that each node will
> > > > contain a full set to data (meaning I can lose 2 of my 3 nodes without
> > > > losing any data).
> > > >
> > > > However I am finding that if I shut down 2 nodes, after adjusting
> > > > minimum\_master\_nodes on the remaining node to 1 and restarting that node,
> > > > the cluster stays yellow with all shards unassigned. They remain in the
> > > > unassigned state until I manually reduce number\_of\_replicas to down 1 or
> > > > 0. Once number\_of\_replicas \<= number of nodes, the shards reassign and the
> > > > cluster goes green. Just wondering if this behaviour is as designed?
> > > >
> > > > Regards,
> > > > Mat
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%
> > > > [40googlegroups.com](http://40googlegroups.com)
> > > > [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > .
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "elasticsearch" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \.
> > > To view this discussion on the web visit
> > > [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com)
> > > [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > .
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@warkolm](https://discuss.elastic.co/u/warkolm)
#### Post date: [January 8, 2015, 11:40pm UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/6 "2015-01-08T23:40:55Z")
It seems highly unusual that this is occurring. I'd recommend that you open
a github issue with details and see what the devs think.
On 8 January 2015 at 09:38, Mathew D [mathew.degerholm@gmail.com](mailto:mathew.degerholm@gmail.com) wrote:
> Good point... actually it looks like the 'head' plugin is misreporting a
> yellow status when replicas=2:
>
> [https://lh4.googleusercontent.com/-nv6MfIzqKuk/VK2x3\_VXgsI/AAAAAAAAASI/EzZ5Ejrw4yo/s1600/cluster-status-with-2-replicas.png](https://lh4.googleusercontent.com/-nv6MfIzqKuk/VK2x3_VXgsI/AAAAAAAAASI/EzZ5Ejrw4yo/s1600/cluster-status-with-2-replicas.png)
> Because when I access the \_cluster/health endpoint, a status of red is
> returned:
>
> {
> "cluster\_name": "KR\_elasticsearch\_PROD",
> "status": "red",
> "timed\_out": false,
> "number\_of\_nodes": 1,
> "number\_of\_data\_nodes": 1,
> "active\_primary\_shards": 0,
> "active\_shards": 0,
> "relocating\_shards": 0,
> "initializing\_shards": 0,
> "unassigned\_shards": 75
> }
>
> So you're correct that the cluster cannot be yellow with primaries
> unassigned. However would still be good to know why ES would refuse to
> allocate primary shards if the number of replicas exceeds the number of
> nodes.
>
> Cheers,
> Mat
>
> On Thursday, January 8, 2015 10:03:51 AM UTC+13, Mark Walkom wrote:
>
> > A cluster cannot be yellow if any primaries are unassigned. Are you sure
> > it's yellow before you set replica's to 0?
> >
> > On 8 January 2015 at 06:52, Mathew D [mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) wrote:
> >
> > > I understand there's no point assigning primaries _and_ replicas to a
> > > single node, but in my case ES won't even allocate a primary (until I
> > > reduce the number of replicas)
> > >
> > > On Wednesday, January 7, 2015 4:58:58 PM UTC+13, Mark Walkom wrote:
> > >
> > > > It's not recommended to run an Elasticsearch cluster across
> > > > geographically dispersed locations.
> > > >
> > > > You cannot assign both primaries and replicas to a single node, it
> > > > defeats the purpose! So it's as design.
> > > >
> > > > On 7 January 2015 at 14:08, Mathew D [mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I've encountered some unexpected behaviour during my DR testing which
> > > > > I'm trying to explain.
> > > > >
> > > > > I have a 3-node geographically-separated cluster with the following
> > > > > settings:
> > > > >
> > > > > - index.number\_of\_shards=5
> > > > > - index.number\_of\_replicas=2
> > > > > - discovery.zen.minimum\_master\_nodes: 2
> > > > >
> > > > > I use number\_of\_replicas=2 for durability, so that each node will
> > > > > contain a full set to data (meaning I can lose 2 of my 3 nodes without
> > > > > losing any data).
> > > > >
> > > > > However I am finding that if I shut down 2 nodes, after adjusting
> > > > > minimum\_master\_nodes on the remaining node to 1 and restarting that node,
> > > > > the cluster stays yellow with all shards unassigned. They remain in the
> > > > > unassigned state until I manually reduce number\_of\_replicas to down 1 or
> > > > > 0. Once number\_of\_replicas \<= number of nodes, the shards reassign and the
> > > > > cluster goes green. Just wondering if this behaviour is as designed?
> > > > >
> > > > > Regards,
> > > > > Mat
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "elasticsearch" group.
> > > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > > msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40goo
> > > > > [glegroups.com](http://glegroups.com)
> > > > > [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > > .
> > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "elasticsearch" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%
> > > > [40googlegroups.com](http://40googlegroups.com)
> > > > [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > .
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "elasticsearch" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
> > To view this discussion on the web visit
> > [https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com)
> > [https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com?utm_medium=email&utm_source=footer)
> > .
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X-FPiG\_zbhvykqFUL%3DSJv9v6\_LCmT8fxBgDpUS9Gp9nWw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X-FPiG_zbhvykqFUL%3DSJv9v6_LCmT8fxBgDpUS9Gp9nWw%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@Mathew\_D](https://discuss.elastic.co/u/Mathew_D)
#### Post date: [January 9, 2015, 3:49am UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/7 "2015-01-09T03:49:51Z")
I've logged this as
[No failover if number\_of\_replicas exceeds number of nodes · Issue #9213 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/9213). Will mark this
thread as complete in favour of the github issue.
On Friday, January 9, 2015 at 12:41:26 PM UTC+13, Mark Walkom wrote:
> It seems highly unusual that this is occurring. I'd recommend that you
> open a github issue with details and see what the devs think.
>
> On 8 January 2015 at 09:38, Mathew D \<[mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) \\>
> wrote:
>
> > Good point... actually it looks like the 'head' plugin is misreporting a
> > yellow status when replicas=2:
> >
> > [https://lh4.googleusercontent.com/-nv6MfIzqKuk/VK2x3\_VXgsI/AAAAAAAAASI/EzZ5Ejrw4yo/s1600/cluster-status-with-2-replicas.png](https://lh4.googleusercontent.com/-nv6MfIzqKuk/VK2x3_VXgsI/AAAAAAAAASI/EzZ5Ejrw4yo/s1600/cluster-status-with-2-replicas.png)
> > Because when I access the \_cluster/health endpoint, a status of red is
> > returned:
> >
> > {
> > "cluster\_name": "KR\_elasticsearch\_PROD",
> > "status": "red",
> > "timed\_out": false,
> > "number\_of\_nodes": 1,
> > "number\_of\_data\_nodes": 1,
> > "active\_primary\_shards": 0,
> > "active\_shards": 0,
> > "relocating\_shards": 0,
> > "initializing\_shards": 0,
> > "unassigned\_shards": 75
> > }
> >
> > So you're correct that the cluster cannot be yellow with primaries
> > unassigned. However would still be good to know why ES would refuse to
> > allocate primary shards if the number of replicas exceeds the number of
> > nodes.
> >
> > Cheers,
> > Mat
> >
> > On Thursday, January 8, 2015 10:03:51 AM UTC+13, Mark Walkom wrote:
> >
> > > A cluster cannot be yellow if any primaries are unassigned. Are you sure
> > > it's yellow before you set replica's to 0?
> > >
> > > On 8 January 2015 at 06:52, Mathew D [mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) wrote:
> > >
> > > > I understand there's no point assigning primaries _and_ replicas to a
> > > > single node, but in my case ES won't even allocate a primary (until I
> > > > reduce the number of replicas)
> > > >
> > > > On Wednesday, January 7, 2015 4:58:58 PM UTC+13, Mark Walkom wrote:
> > > >
> > > > > It's not recommended to run an Elasticsearch cluster across
> > > > > geographically dispersed locations.
> > > > >
> > > > > You cannot assign both primaries and replicas to a single node, it
> > > > > defeats the purpose! So it's as design.
> > > > >
> > > > > On 7 January 2015 at 14:08, Mathew D [mathew.d...@gmail.com](mailto:mathew.d...@gmail.com) wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I've encountered some unexpected behaviour during my DR testing which
> > > > > > I'm trying to explain.
> > > > > >
> > > > > > I have a 3-node geographically-separated cluster with the following
> > > > > > settings:
> > > > > >
> > > > > > - index.number\_of\_shards=5
> > > > > > - index.number\_of\_replicas=2
> > > > > > - discovery.zen.minimum\_master\_nodes: 2
> > > > > >
> > > > > > I use number\_of\_replicas=2 for durability, so that each node will
> > > > > > contain a full set to data (meaning I can lose 2 of my 3 nodes without
> > > > > > losing any data).
> > > > > >
> > > > > > However I am finding that if I shut down 2 nodes, after adjusting
> > > > > > minimum\_master\_nodes on the remaining node to 1 and restarting that node,
> > > > > > the cluster stays yellow with all shards unassigned. They remain in the
> > > > > > unassigned state until I manually reduce number\_of\_replicas to down 1 or
> > > > > > 0. Once number\_of\_replicas \<= number of nodes, the shards reassign and the
> > > > > > cluster goes green. Just wondering if this behaviour is as designed?
> > > > > >
> > > > > > Regards,
> > > > > > Mat
> > > > > >
> > > > > > --
> > > > > > You received this message because you are subscribed to the Google
> > > > > > Groups "elasticsearch" group.
> > > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > > > send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > > > msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40goo
> > > > > > [glegroups.com](http://glegroups.com)
> > > > > > [https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/abb0e7cd-c11a-4914-a98f-70d68c1d17be%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > > > .
> > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "elasticsearch" group.
> > > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).
> > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)
> > > > > msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%
> > > > > [40googlegroups.com](http://40googlegroups.com)
> > > > > [https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/74ae6254-e4c5-4504-8bee-cd337666bea4%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > > > .
> > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "elasticsearch" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \.
> > > To view this discussion on the web visit
> > > [https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com)
> > > [https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/fbbf2012-5d5f-42f4-b388-762a997b8fc9%40googlegroups.com?utm_medium=email&utm_source=footer)
> > > .
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/91a20069-ab08-41a5-8c73-7674eb0a8128%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/91a20069-ab08-41a5-8c73-7674eb0a8128%40googlegroups.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 12:39am UTC](https://discuss.elastic.co/t/no-failover-if-number-of-replicas-exceeds-number-of-nodes/21514/8 "2017-07-06T00:39:57Z")