Changing EC2 instance ID of a data node but keeping the data volume?

Elastic Stack Elasticsearch
1

Hello,

I'm planning a rolling upgrade of our ES cluster from ES 1.3.2 to ES 1.5.0,
hosted on AWS.

I read the instructions
at http://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html
which seem to be pretty straight forward but it doesn't address issues like
using an automatic provisioning system like Puppet/Chef, and generally
rebuilding nodes after a disaster.

What I'd like to do is to be able to rebuild dead nodes from scratch using
Puppet, take advantage of the flexibility of the cloud, and the fact that
we put all our ES data on a separate detachable volumes ("/dev/sdb").

For this, I'd like to be able to do something like:

  1. Stop replication (to avoid unnecessary shard reshuffling, as
    suggested in the link above)
  2. Stop an ES node software.
  3. Stop the EC2 instance (not terminate it), detach the data volume from
    it.
  4. Use some CloudFormation, UserData and Puppet magic to bring up a new
    EC2 node and attach the data volume to it
  5. Configure the new data node using Puppet to install ES 1.5.0 on it
  6. Start ES, make it join the cluster and make the cluster aware that it
    still got the data from the volume of the old node.

But my colleague tells me that this wont work because, as far as he can
tell, the shard is identified also by the the EC2 Instance ID (the
"i-xxxxxxx" identifier), and therefore the new instance will not be heard
when it tells the cluster that it has the data from the old node.

Is this correct?

What do others here do to address EC2 instance loss? Just replicate even if
the data is still available in the separate volume?

Thanks.

--
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/a3937256-0d52-41a1-a981-7e6e5a7614f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

IMHO there is no correlation between instance id and whatever shard id.

As soon as your new Elasticsearch instance can see the data, I think it should work fine.

A simple test on a test instance should help you verifying your upgrade process.

David

Le 26 mars 2015 à 07:04, Amos S amos.shapira@gmail.com a écrit :

Hello,

I'm planning a rolling upgrade of our ES cluster from ES 1.3.2 to ES 1.5.0, hosted on AWS.

I read the instructions at Upgrade Elasticsearch | Elasticsearch Guide [8.11] | Elastic which seem to be pretty straight forward but it doesn't address issues like using an automatic provisioning system like Puppet/Chef, and generally rebuilding nodes after a disaster.

What I'd like to do is to be able to rebuild dead nodes from scratch using Puppet, take advantage of the flexibility of the cloud, and the fact that we put all our ES data on a separate detachable volumes ("/dev/sdb").

For this, I'd like to be able to do something like:
Stop replication (to avoid unnecessary shard reshuffling, as suggested in the link above)
Stop an ES node software.
Stop the EC2 instance (not terminate it), detach the data volume from it.
Use some CloudFormation, UserData and Puppet magic to bring up a new EC2 node and attach the data volume to it
Configure the new data node using Puppet to install ES 1.5.0 on it
Start ES, make it join the cluster and make the cluster aware that it still got the data from the volume of the old node.
But my colleague tells me that this wont work because, as far as he can tell, the shard is identified also by the the EC2 Instance ID (the "i-xxxxxxx" identifier), and therefore the new instance will not be heard when it tells the cluster that it has the data from the old node.

Is this correct?

What do others here do to address EC2 instance loss? Just replicate even if the data is still available in the separate volume?

Thanks.

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/a3937256-0d52-41a1-a981-7e6e5a7614f7%40googlegroups.com.
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/3401FA8B-EE2D-413B-A5AF-F0404203F44E%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.