I have a question about upgrading: should you turn off shard reallocation
before shutting down each server?
I was reading somewhere (but can't find where) that shutting down a node in
the cluster reassigns all the shards immediately and then bringing the node
back up causes another flurry of reassignments. This is the behaviour I
see.
If I turn off shard reallocation before shutting down the server, upgrade,
restart, then turn on shard reallocation, then I see the shards basically
snap back to their old server and the whole process seems to proceed much
more quickly.
So, is this how I should do a rolling upgrade? If so, should I work on
building such a thing into the deb package, shutdown api, or something else?
During an upgrade I would also disable automatic shard allocation during an
upgrade in order to prevent behaviour that you're describing. I don't know
much about deb packages, but if that automates that process (disable before
upgrade and enable after) I think that would be a good idea.
On 18 September 2013 21:12, Nikolas Everett nik9000@gmail.com wrote:
I have a question about upgrading: should you turn off shard reallocation
before shutting down each server?
I was reading somewhere (but can't find where) that shutting down a node
in the cluster reassigns all the shards immediately and then bringing the
node back up causes another flurry of reassignments. This is the behaviour
I see.
If I turn off shard reallocation before shutting down the server, upgrade,
restart, then turn on shard reallocation, then I see the shards basically
snap back to their old server and the whole process seems to proceed much
more quickly.
So, is this how I should do a rolling upgrade? If so, should I work on
building such a thing into the deb package, shutdown api, or something else?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.