The upgrade proces is different if you want to reindex data compared to
upgrading a version. If you need to reindex data, then you can use an
existing cluster and reindex into a new index / indices. Then, you can use
aliases to switch to the "new version".
Regarding upgrading elasticsearch versions, if its a minor version, you can
do a rolling restart. If its a major version, then you need to do a full
restart. Note, sometimes, it just make sense to do a full restart as it
requires less data to be moved around. There is an issue open to try and
address rebalancing when doing rolling restart, though tricky
On Wed, Aug 17, 2011 at 3:10 PM, Lukáš Vlček email@example.com wrote:
OK, looking forward to the next releases with optimism
I can live without it for now, I will just go with minimum master nodes = 1
and cross my fingers to not experience split brains. Would there be any
recommendation regarding the upgrade process that I described? Is it a good
idea and are there any settings that I should pay attention to in this case?
On Wed, Aug 17, 2011 at 1:43 PM, Shay Banon firstname.lastname@example.org wrote:
You can't update the settings in realtime. There are two aspects of
elasticsearch that are missing in terms of realtime updates of settings.
They are cluster wide settings and node level settings. Both should be
On Wed, Aug 17, 2011 at 11:48 AM, Lukáš Vlček email@example.com:
is it possible to update minimum_master_nodes value via Update API?
I am thinking of the following cluster upgrade scenario:
Let's say I have a 3 node cluster (in this case the minimum_master_nodes
should be set probably to 2). If there are 3 nodes I think it is possible to
do an upgrade of search service without downtime. For example if I need to
upgrade to a new version of ES or I need to do a significant update to
mappings I can simply take one node out of that 3 node cluster, upgrade it,
re-index data into it if needed, take another node from the 2 node cluster,
upgrade it as well and have it form a new cluster with the newly upgraded
node and have data replicated. Redirect clients to the new cluster, shutdown
the last remaining node from the original cluster, upgrade it and have it
join the new cluster. Given that the network traffic from clients won't be
high such upgrade strategy should be possible (hopefully?). But the problem
is that if the minimum_master_nodes can not be updated then it is not
possible to do such upgrade (the other option would be to set the master
number value to 1).