However, is this Shutdown API graceful? Does it just drop all connections
to said node, or does it block future HTTP connections and drain the
existing ones (like what one might expect from, say, CouchDB).
Additionally, is there any way to restart from the Shutdown API, or would I
be needing to ssh into said machine and re-run service elasticsearch start (from the servicewrapper plugin)
However, is this Shutdown API graceful? Does it just drop all connections
to said node, or does it block future HTTP connections and drain the
existing ones (like what one might expect from, say, CouchDB).
Additionally, is there any way to restart from the Shutdown API, or would
I be needing to ssh into said machine and re-run service elasticsearch start (from the servicewrapper plugin)
As long as you have replicas, the node shutdown operation, when issued
one by one and waiting for a green state, is graceful from the cluster's
point of view. Note, it is not graceful for clients, they have to manage
failover to another node for themselves. They will see connection
failures if the node they talk to is being shut down.
There is a restart method in the Shutdown API (here, the REST version)
curl -XPOST /_cluster/nodes/_restart
curl -XPOST /_cluster/nodes/{nodeId}/_restart
which might be handy in a few cases, e.g. for reloading updated plugins
without service interruption.
If you control ES from the service wrapper, you should stop/restart a
node from there.
Jörg
Am 01.03.13 20:45, schrieb sr-ix:
However, is this Shutdown API graceful? Does it just drop all
connections to said node, or does it block future HTTP connections and
drain the existing ones (like what one might expect from, say, CouchDB).
Additionally, is there any way to restart from the Shutdown API, or
would I be needing to ssh into said machine and re-run service elasticsearch start (from the servicewrapper plugin)
If you place Elasticsearch behind a load-balancer, the cluster maintenance
can be made fully transparent to clients:
Add node IP to cluster exclude list
Configure load-balancer to drain the node, allowing existing connections
to finish
When the load-balancer shows zero connections and the cluster has
relocated all the shards on the node, shut it down
After starting the node back up and confirming that it is valid, remove
the node IP from the cluster exclude list and enable it on the load-balancer
-Pradeep
On Friday, May 17, 2013 7:35:25 AM UTC-7, Jörg Prante wrote:
As long as you have replicas, the node shutdown operation, when issued
one by one and waiting for a green state, is graceful from the cluster's
point of view. Note, it is not graceful for clients, they have to manage
failover to another node for themselves. They will see connection
failures if the node they talk to is being shut down.
There is a restart method in the Shutdown API (here, the REST version)
curl -XPOST /_cluster/nodes/_restart
curl -XPOST /_cluster/nodes/{nodeId}/_restart
which might be handy in a few cases, e.g. for reloading updated plugins
without service interruption.
If you control ES from the service wrapper, you should stop/restart a
node from there.
Jörg
Am 01.03.13 20:45, schrieb sr-ix:
However, is this Shutdown API graceful? Does it just drop all
connections to said node, or does it block future HTTP connections and
drain the existing ones (like what one might expect from, say, CouchDB).
Additionally, is there any way to restart from the Shutdown API, or
would I be needing to ssh into said machine and re-run service elasticsearch start (from the servicewrapper plugin)
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.