Optimization/Merging space

[David Hastings <ha...@gmail.com>]

Hi all, I am curious to know what happens when solr begins a merge/optimize
operation, but then runs out of physical disk space.  I havent had the
chance to try this out yet but I was wondering if anyone knows what the
underlying codes response to the situation would be if it happened.  Thanks
-David

Re: Optimization/Merging space

[Erick Erickson <er...@gmail.com>]

Bad Things Can Happen. Solr (well, Lucene in this case) tries very
hard to keep disk full operations from having repercussions., but it's
kind of like OOMs. What happens next?

It's not so much the merge/optimize, but what happens in the future
when the _next_ segment is written...

The merge or optimize goes something like this:

1> copy and merge all the segments you intend to
2> when all that is successful, update the segments file
3> delete the old segments.

So theoretically if your disk fills up during <1> or <2> your old
index is intact and usable. It isn't until the segments file has been
successfully changed that the new snapshot of the index is active.
Which, in a nutshell, is why you need to have at least as much free
space on your disk as your index occupies since you can't control when
a merge happens which may copy _all_ of your segments to new ones.

Let's say that during <1> your disk fills up _and_ you're indexing new
documents at the same time. Solr/Lucene can't guarantee that the new
documents got written to disk in that case. So while your current
snapshot is probably OK, your index may not be in the state you want.
Meanwhile if you're using transaction logs Solr is trying to write
tlogs to disk. It's unknown what happened to them (another good
argument for putting them on a separate disk!).

Best,
Erick



On Wed, Jul 5, 2017 at 9:07 AM, David Hastings
<ha...@gmail.com> wrote:
> Hi all, I am curious to know what happens when solr begins a merge/optimize
> operation, but then runs out of physical disk space.  I havent had the
> chance to try this out yet but I was wondering if anyone knows what the
> underlying codes response to the situation would be if it happened.  Thanks
> -David