# Changing EC2 instance ID of a data node but keeping the data volume? **URL:** \ **Category:** Elasticsearch\ **Created:** [March 26, 2015, 6:04am UTC](https://discuss.elastic.co/t/changing-ec2-instance-id-of-a-data-node-but-keeping-the-data-volume/22914 "2015-03-26T06:04:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Amos\_S](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/amos_s/32/720_2.png) [@Amos\_S](https://discuss.elastic.co/u/Amos_S)\ **Post date:** [March 26, 2015, 6:04am UTC](https://discuss.elastic.co/t/changing-ec2-instance-id-of-a-data-node-but-keeping-the-data-volume/22914/1 "2015-03-26T06:04:58Z")
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](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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/a3937256-0d52-41a1-a981-7e6e5a7614f7%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [March 26, 2015, 6:48am UTC](https://discuss.elastic.co/t/changing-ec2-instance-id-of-a-data-node-but-keeping-the-data-volume/22914/2 "2015-03-26T06:48:44Z")
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](mailto: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](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: > 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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/a3937256-0d52-41a1-a981-7e6e5a7614f7%40googlegroups.com). > For more options, visit [https://groups.google.com/d/optout](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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/3401FA8B-EE2D-413B-A5AF-F0404203F44E%40pilato.fr). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:23am UTC](https://discuss.elastic.co/t/changing-ec2-instance-id-of-a-data-node-but-keeping-the-data-volume/22914/3 "2017-07-06T00:23:52Z")