Is re-election/assignment of the master node possible?

Elastic Stack Elasticsearch
1

Is there any notion triggering a re-election of the master node?

I'm currently running 1.2.4, and I have an instance that is scheduled for
retirement (my favorite!) and it just so happens that it's my master node.
What can I do to avoid the dreaded "RED" state? Is there some mechanism
that can allow me to re-assign the current master to one of the other
available two dedicated master nodes so I can reboot the current master?

I ask because I'm a bit gun-shy due to my experience when an elected master
node has gone unresponsive (before I created dedicated masters) due to
excessive HTTP connections, master re-election seemed to never occur and
everything comes crumbling down.

Thanks!

  • Erik

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/80d7ec69-40e6-46d6-8de1-159d6117a7c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

On Wed, Nov 26, 2014 at 3:47 PM, Erik theRed j.e.redding@gmail.com wrote:

Is there any notion triggering a re-election of the master node?

I'm currently running 1.2.4, and I have an instance that is scheduled for
retirement (my favorite!) and it just so happens that it's my master node.
What can I do to avoid the dreaded "RED" state? Is there some mechanism
that can allow me to re-assign the current master to one of the other
available two dedicated master nodes so I can reboot the current master?

Move all the shards off of the node using allocation include/exclude
settings. If you shoot the master one of the other master eligible nodes
will take over quickly and there won't be any interruptions.

I ask because I'm a bit gun-shy due to my experience when an elected
master node has gone unresponsive (before I created dedicated masters) due
to excessive HTTP connections, master re-election seemed to never occur and
everything comes crumbling down.

I've never had that problem. My cluster is pretty small though - only 31
nodes.

Nik

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2qctbbzPgH4iKTw1TvRymCL125zXymAeFUo9%3D84COLXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

3

Thanks, Nik -

There's no data on the node so it sounds like master reelection should fail
over fairly quickly.

On Wednesday, November 26, 2014 2:58:43 PM UTC-6, Nikolas Everett wrote:

On Wed, Nov 26, 2014 at 3:47 PM, Erik theRed <j.e.r...@gmail.com
<javascript:>> wrote:

Is there any notion triggering a re-election of the master node?

I'm currently running 1.2.4, and I have an instance that is scheduled for
retirement (my favorite!) and it just so happens that it's my master node.
What can I do to avoid the dreaded "RED" state? Is there some mechanism
that can allow me to re-assign the current master to one of the other
available two dedicated master nodes so I can reboot the current master?

Move all the shards off of the node using allocation include/exclude
settings. If you shoot the master one of the other master eligible nodes
will take over quickly and there won't be any interruptions.

I ask because I'm a bit gun-shy due to my experience when an elected
master node has gone unresponsive (before I created dedicated masters) due
to excessive HTTP connections, master re-election seemed to never occur and
everything comes crumbling down.

I've never had that problem. My cluster is pretty small though - only 31
nodes.

Nik

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b9506885-e321-4abe-b1c2-db0d802b07ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

The load issue affecting master detection / election shouldn't happen if
you have dedicated masters... At least it is with 0.90.x

( with my limited knowledge of ES implementation details, there seems to be
a lock or priority issue when serving large # of requests (http / thrift) ,
affecting cluster / metadata updates... I would think these metadata tasks
ought to take priority in some cases over queries... )
On 26/11/2014 6:11 pm, "Erik theRed" j.e.redding@gmail.com wrote:

Thanks, Nik -

There's no data on the node so it sounds like master reelection should
fail over fairly quickly.

On Wednesday, November 26, 2014 2:58:43 PM UTC-6, Nikolas Everett wrote:

On Wed, Nov 26, 2014 at 3:47 PM, Erik theRed j.e.r...@gmail.com wrote:

Is there any notion triggering a re-election of the master node?

I'm currently running 1.2.4, and I have an instance that is scheduled
for retirement (my favorite!) and it just so happens that it's my master
node. What can I do to avoid the dreaded "RED" state? Is there some
mechanism that can allow me to re-assign the current master to one of the
other available two dedicated master nodes so I can reboot the current
master?

Move all the shards off of the node using allocation include/exclude
settings. If you shoot the master one of the other master eligible nodes
will take over quickly and there won't be any interruptions.

I ask because I'm a bit gun-shy due to my experience when an elected
master node has gone unresponsive (before I created dedicated masters) due
to excessive HTTP connections, master re-election seemed to never occur and
everything comes crumbling down.

I've never had that problem. My cluster is pretty small though - only 31
nodes.

Nik

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/b9506885-e321-4abe-b1c2-db0d802b07ec%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/b9506885-e321-4abe-b1c2-db0d802b07ec%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CACj2-4J8Ycj07jhHdX71JJjAHW0_ZALMH9mPUcW1__sF_1NagA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

5

As soon as we surf the internet and looking for the jammer products we can see that there are various types of signal jammers that are for sale in the market now such as the mobile phone jammers, gps jammers, wifi jammers, UHF jammers, the multi-functional signal jammers and so many others kinds of signal jammers for sale as well. And what people now need to do is just select the best one according to their needs.