I just tried a similar technique on 0.14.2, but it doesn't appear to
be working as I'd expect. I've tried this a couple of times and have
gotten exact same results.
- Have a three node cluster with local gateway
- Updated replica count to 2, so that every machine will have all the
- Stopped a node, which should now have a full copy of the index data
- I then try to rename the cluster on this node by renaming the data
directory and updating the elasticsearch.yml file to a new cluster
name. I also tweak the config file to only expect one node
- I start things up and it appears that a few empty indexes get picked
up correctly, but nothing with data loads. The new cluster just sits
there in a red state.
I bumped up logging to ALL and captured this log:
Any ideas if I am doing something wrong or hitting a 14.2 issue?
On Feb 28, 12:11 pm, Shay Banon shay.ba...@elasticsearch.com wrote:
If the change requires reindexing, then you need to get the docs and index them. The best way is to just get them from the original place where they are stored, or, in upcoming 0.16, use the scan API.
If your change does not require reindexing (no mappings were changed / no need to change the number of shards), then you can simply copy over the gateway data (if you using shared gateway), and copy over to each node the "data" directory of existing nodes (this also applied when using the "local" gateway).
On Monday, February 28, 2011 at 2:23 PM, Paul Loy wrote:
we're getting close to a production release with elastic search as one of the components in our system. From time-to-time we will want to update ES and also possibly redistribute (change the sharding / replication) the cluster. We think the safest way to do this is probably to start another cluster and migrate the data over. What do you think the best (quickest?) option would be:
- read from the gateway (is this possible for redistribution?)
- pull the data from the existing cluster into the new cluster using
a) elastic search River?
b) custom script / app to pull data across