Node never gets its share of the shards

Elastic Stack Elasticsearch
1

Hi

I have a simple setup with four ES nodes (192.168.88.140-143) in
cluster. The nodes are started at almost the same time and shortly
after client nodes are started. The client nodes create one index with
12 shards (and 1 replica) and start indexing documents into those. It
works ok.

I look at the ES cluster through elasticsearch-head. I see that there
are no shards assigned to one of the nodes (the one at
192.168.88.140), and that node appear on a yellow background in
elasticsearch-head - the other 3 nodes appear on a white background.
Besides that I do not notice any problem with 192.168.88.140, would
explain why it does not get shards assigned.

Can anyone help explain why 192.168.88.140 does not get its fair share
of the shards?

Regards, Per Steffensen

2

That's your master node. You probably have:

node.master: true
node.data: false

in the configuration file for that node.

Thibaut

On Mon, Oct 10, 2011 at 12:42 PM, Steff steff@designware.dk wrote:

Hi

I have a simple setup with four ES nodes (192.168.88.140-143) in
cluster. The nodes are started at almost the same time and shortly
after client nodes are started. The client nodes create one index with
12 shards (and 1 replica) and start indexing documents into those. It
works ok.

I look at the ES cluster through elasticsearch-head. I see that there
are no shards assigned to one of the nodes (the one at
192.168.88.140), and that node appear on a yellow background in
elasticsearch-head - the other 3 nodes appear on a white background.
Besides that I do not notice any problem with 192.168.88.140, would
explain why it does not get shards assigned.

Can anyone help explain why 192.168.88.140 does not get its fair share
of the shards?

Regards, Per Steffensen

3

On 10 Okt., 12:48, Thibaut Britz thibaut.br...@trendiction.com
wrote:

That's your master node. You probably have:

node.master: true
node.data: false

in the configuration file for that node.

Nope. I have the same config, saying nothing about node.master or
node.data, for all 4 nodes. I hope (for the sake of HA) that you do
not have to point out a master in a config file.

I should also say that sometimes when I start the same simple test in
the same simple setup, all four nodes gets their share of the shards.
It is only sometimes that this "problem" occur.

Thibaut

On Mon, Oct 10, 2011 at 12:42 PM, Steff st...@designware.dk wrote:

Hi

I have a simple setup with four ES nodes (192.168.88.140-143) in
cluster. The nodes are started at almost the same time and shortly
after client nodes are started. The client nodes create one index with
12 shards (and 1 replica) and start indexing documents into those. It
works ok.

I look at the ES cluster through elasticsearch-head. I see that there
are no shards assigned to one of the nodes (the one at
192.168.88.140), and that node appear on a yellow background in
elasticsearch-head - the other 3 nodes appear on a white background.
Besides that I do not notice any problem with 192.168.88.140, would
explain why it does not get shards assigned.

Can anyone help explain why 192.168.88.140 does not get its fair share
of the shards?

Regards, Per Steffensen

4

I run without replica. The node that does not get any shards might
somehow join the cluster millisecs after the index has been created
and shards initially assigned (to the other nodes). Is ES able to
reassign (move) shards that does not have any replica? If not, that
might be the explanation?!?

Regards

5

On Tue, 2011-10-11 at 00:08 -0700, Steff wrote:

I run without replica. The node that does not get any shards might
somehow join the cluster millisecs after the index has been created
and shards initially assigned (to the other nodes). Is ES able to
reassign (move) shards that does not have any replica? If not, that
might be the explanation?!?

ES should move shards around to rebalance the cluster. Are you
absolutely sure that that node has joined the cluster?

When starting a number of nodes at once, the transfer of data from one
node to another can make nodes slow to respond to cluster join requests,
which can cause a new node to think that it is alone and should start
its own cluster.

The speed of recovery can be tuned:

clint

6

Also, double check that no shards are allocated on that node using the
cluster state API (on top of making sure you see in the log that the node
joined the cluster).

On Tue, Oct 11, 2011 at 10:50 AM, Clinton Gormley clint@traveljury.comwrote:

On Tue, 2011-10-11 at 00:08 -0700, Steff wrote:

I run without replica. The node that does not get any shards might
somehow join the cluster millisecs after the index has been created
and shards initially assigned (to the other nodes). Is ES able to
reassign (move) shards that does not have any replica? If not, that
might be the explanation?!?

ES should move shards around to rebalance the cluster. Are you
absolutely sure that that node has joined the cluster?

When starting a number of nodes at once, the transfer of data from one
node to another can make nodes slow to respond to cluster join requests,
which can cause a new node to think that it is alone and should start
its own cluster.

The speed of recovery can be tuned:
Elasticsearch Platform — Find real-time answers at scale | Elastic

clint