Thanks Shawn! I will definitely be interested to explore this space cautiously in that case.
This was a ton of great info I needed, and more than I initially knew to ask :) Your first response seems to imply an answer to my original question, but I wanted to follow up to be as sure as I can. In the recovery scenario, are there situations where a complete index will copy over next to the original index, thus requiring 2x the disk space? Or is that now outdated? I could imagine for example the replacement is now done on each segment at a smaller scale or something along those lines and so recovery requirements would expect to be on par with merge requirements, or perhaps there is some "bad enough" scenario where a full side-by-side copy is made during recovery. Can you comment on that? Thanks! On Tue, Jun 22, 2021 at 5:33 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 6/22/2021 5:02 PM, Stephen Lewis Bianamara wrote: > > The merging considerations are certainly interesting and naunced. Has > there > > been any investigation into a "minimum number of segments" setting which > > could force a minimum number of segments (say 5 or 10) so that no one > > segment operation could involve the entire index? > > > Since Solr 7.5, the merge defaults are a lot better. I think the "no > segment larger than 5GB" setting even applies to optimize, but I'm not > completely positive. Erick Erickson is familiar with the nitty gritty > details on that. > > If you never run an optimize, you should be fine. And since you go with > the A/B option for reindexing, you might not ever run into the 3x > requirement. But if you're dealing with bare metal servers, disks are > cheap, so it's a good idea to have LOTS of free space. If you're going > AWS or some other cloud solution, you'll probably want to be more aware > of realistic requirements. > > Thanks, > Shawn > >
