Hi,
My testing has done a little bit of what you're describing...
- FWIW and I don't know why, when I re-insert the data from scratch instead
of upgrading a cluster, I'm seeing substantial improvements in node general
health. They seem faster, less latencies related to indexing (I assume
there should be no diff searching, but ??). If a reason why I'm seeing this
can't be found, then maybe what I'm seeing is specific to my setup and
hardware.
- I don't know that there should be any reason to name your cluster
differently if the networks are completely isolated, but of course if there
should be a mistake, the consequences could be serious.
- I've been using various methods that display index activity, the easiest
to use (and today work on both 0.90 and 1.0) are elasticsearch-head and
elasticsearch-hq. I've also been toying around recently with simply probing
each node using a curl command, which depending on how you deploy web tools
likely has a lower load effect on resources (I'm currently running Apache
on one node and when I use one or more of the above tools, has a
significant and measurable load).
- If you do an upgrade, at least the one time after the upgrade you may
want to force your cluster to wait until all nodes in the cluster are
active before restarting to minimize shard thrashing (if a node is not
online yet, the cluster may discard the indices on that node and
re-allocate from whatever copy already is active. Then, when the missing
node finally joins, then the shards are re-balanced). One way to do that is
setting the following to be the same as the total nodes in the cluster
gateway.recovery_after_nodes
HTH,
Tony
On Wednesday, February 19, 2014 7:01:03 AM UTC-8, Attila Bukor wrote:
> Hey everybody,
>
> I have a question regarding the migration of the indices to a new cluster
> seamlessly. Let me first describe the situation:
>
> I have a project which uses Elasticsearch since a few weeks ago. This is
> our
> first Elasticsearch project, and as we are satisfied with it, we decided
> to
> dedicate a cluster of 3 nodes to run Elasticsearch (lets call it
> "newcluster"). It is up and running separately from our old 1-node
> Elasticsearch installation ("oldcluster"). We want to migrate everything
> to
> newcluster, and turn oldcluster off. All 4 servers are running Ubuntu
> Server,
> Elasticsearch is installed from the official deb package, oldcluster is
> 0.90.10 and newcluster 1.0.0.
>
> I came up with the following solution, but I'm not sure it will work:
>
> - Upgrade oldcluster to 1.0.0 (tested it in dev, should work)
> - Backup the index (we have only one index right now) in case something
> goes
> wrong.
> - Change oldcluster's name to newcluster.
> - Wait until the nodes synchronize themselves (how can I check if they're
> in
> sync?)
> - Shut down oldcluster.
>
> Thank you very much,
> Attila
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/5a1c622f-4ac5-4203-ab00-d66facb227a9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
