Disabling allocation helps, but it does not solve the problem completely. Just like Nik, one of my complaints (although not my primary one). :)
I found that recovery gets easier when doing a rolling restart. First few servers always rebalance, the last ones do not. -- Ivan On Thu, Nov 20, 2014 at 9:51 PM, Mark Walkom <markwal...@gmail.com> wrote: > You should disable allocation before you reboot, that will save a lot of > shard shuffling - > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades > > On 21 November 2014 13:48, Konstantin Erman <kon...@gmail.com> wrote: > >> I work on an experimental cluster of ES nodes running on Windows Server >> machines. Once in a while we have a need to reboot machines. The initial >> state - cluster is green and well balanced. One machine is gracefully taken >> offline and then after necessary service is performed it comes back online. >> All the hardware and file system content is intact. As soon as ES service >> starts on that machine, it assumes that there is no usable data locally and >> recovers as much data as it deems necessary for balancing from other nodes. >> >> This behavior puzzles me, because most of the data shards stored on that >> machine file system can be reused as they are. Cluster stores logs, so all >> indices except those for the current day never ever change until they get >> deleted. Can't ES node detect that it has perfect copies of some (actually >> most) of the shards and instead of copying them over just mark them as up >> to date? >> >> I suspect I don't know about some step to enable this behavior and I'm >> looking to enable it. Any advice? >> >> Thank you! >> Konstantin >> >> -- >> 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+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/4fb2d8bc-7787-43e3-8c66-e241945d496b%40googlegroups.com >> <https://groups.google.com/d/msgid/elasticsearch/4fb2d8bc-7787-43e3-8c66-e241945d496b%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAF3ZnZmc_rMFzRUUrJSMJ9bY16tz-dZ8eSeUZobC7XaxWZTRPg%40mail.gmail.com > <https://groups.google.com/d/msgid/elasticsearch/CAF3ZnZmc_rMFzRUUrJSMJ9bY16tz-dZ8eSeUZobC7XaxWZTRPg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQDjm%3DvBT7U3%3DQXwZzz83Bf52t21KYZwCuqdYgGJhXKuhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
