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+unsubscr...@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.
