All shards in started but wont go to ready

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 5,
"number_of_data_nodes" : 5,
"active_primary_shards" : 97,
"active_shards" : 389,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 1

here is the output to a _status

after filling this out i figured out what it was but wanted to know if this
is expected.

I have an index that with a single shard and its replication is set to 5
what ever means priamry plus 5 copies. I killed one node days ago and then
rebooted the clusters today. but it would not allocate that 1 shard that it
did not have a machine for? So it blocked everything else. I would think
since there are 5 other copies of the data and the other 5 were active much
longer then this other shard it should have been fine to boot up. the
moment i added a machine to the cluster it got that extra copy. and
everything was fine.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

So you have one index with 1 shard and 5 replica on a 5 nodes cluster.
Elasticsearch needs to allocate 6 shards on the cluster.

So you need to bring up one more node.

That said, it's not really a concern here. I mean that your cluster is running fine and continue to serve all requests.

You can decrease live the number of replica if you want to get back your cluster to a green status.

--
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet | @elasticsearchfr

Le 12 novembre 2013 at 12:13:23, Alexis Okuwa (wojonstech@gmail.com) a écrit:

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 5,
"number_of_data_nodes" : 5,
"active_primary_shards" : 97,
"active_shards" : 389,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 1

here is the output to a _status https://gist.github.com/wojons/921c23e84d0a2d1238b3

after filling this out i figured out what it was but wanted to know if this is expected.

I have an index that with a single shard and its replication is set to 5 what ever means priamry plus 5 copies. I killed one node days ago and then rebooted the clusters today. but it would not allocate that 1 shard that it did not have a machine for? So it blocked everything else. I would think since there are 5 other copies of the data and the other 5 were active much longer then this other shard it should have been fine to boot up. the moment i added a machine to the cluster it got that extra copy. and everything was fine.

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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

David,

Thank you very much yeah i figured as much thats why i turned on the extra
server but to me that does not make sense since its not like a 3 to 2 win
but a 5-1 votting.

On Tuesday, November 12, 2013 3:20:50 AM UTC-8, David Pilato wrote:

So you have one index with 1 shard and 5 replica on a 5 nodes cluster.
Elasticsearch needs to allocate 6 shards on the cluster.

So you need to bring up one more node.

That said, it's not really a concern here. I mean that your cluster is
running fine and continue to serve all requests.

You can decrease live the number of replica if you want to get back your
cluster to a green status.

--
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet https://twitter.com/dadoonet | @elasticsearchfrhttps://twitter.com/elasticsearchfr

Le 12 novembre 2013 at 12:13:23, Alexis Okuwa (wojon...@gmail.com<javascript:>)
a écrit:

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 5,
"number_of_data_nodes" : 5,
"active_primary_shards" : 97,
"active_shards" : 389,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 1

here is the output to a _status
_status · GitHub

after filling this out i figured out what it was but wanted to know if
this is expected.

I have an index that with a single shard and its replication is set to 5
what ever means priamry plus 5 copies. I killed one node days ago and then
rebooted the clusters today. but it would not allocate that 1 shard that it
did not have a machine for? So it blocked everything else. I would think
since there are 5 other copies of the data and the other 5 were active much
longer then this other shard it should have been fine to boot up. the
moment i added a machine to the cluster it got that extra copy. and
everything was fine.

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 <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.