[
https://issues.apache.org/jira/browse/SOLR-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640204#comment-14640204
]
Ramkumar Aiyengar commented on SOLR-7820:
-----------------------------------------
-0. As Mark mentions, its a scary place to be in already. However advanced you
make this, it's still going to be one more "optimize" like feature. Ooh, saves
space, let's turn this on! Yes, it will, but it carries a risk which is not
easily quantifiable. We still have cases where the entire cloud can go to
recovery. They are rare with all our fixes over time, but they still exist. If
you are serious/demanding enough about your search index to procure SSDs, you
don't want to wake up finding your index gone just because you were feeling
wise with your dollars one day in the past. I am still -0 with this only
because I don't foresee any *technical* issues with this, but still doesn't
sound like a feature we want to have.
> IndexFetcher should delete the current index directory before downloading the
> new index when isFullCopyNeeded==true
> -------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7820
> URL: https://issues.apache.org/jira/browse/SOLR-7820
> Project: Solr
> Issue Type: Improvement
> Components: replication (java)
> Reporter: Timothy Potter
>
> When a replica is trying to recover and it's IndexFetcher decides it needs to
> pull the full index from a peer (isFullCopyNeeded == true), then the existing
> index directory should be deleted before the full copy is started to free up
> disk to pull a fresh index, otherwise the server will potentially need 2x the
> disk space (old + incoming new). Currently, the IndexFetcher removes the
> index directory after the new is downloaded; however, once the fetcher
> decides a full copy is needed, what is the value of the existing index? It's
> clearly out-of-date and should not serve queries. Since we're deleting data
> preemptively, maybe this should be an advanced configuration property, only
> to be used by those that are disk-space constrained (which I'm seeing more
> and more with people deploying high-end SSDs - they typically don't have 2x
> the disk capacity required by an index).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
