[ 
https://issues.apache.org/jira/browse/SOLR-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643329#comment-14643329
 ] 

Ramkumar Aiyengar commented on SOLR-7820:
-----------------------------------------

In Yonik's words..

https://issues.apache.org/jira/browse/SOLR-6460?focusedCommentId=14117807&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14117807

> IndexFetcher should calculate ahead of time how much space is needed for full 
> snapshot based recovery and cleanly abort instead of trying and running out 
> of space on a node
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 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

Reply via email to