You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Timothy Potter (JIRA)" <ji...@apache.org> on 2015/07/27 18:42:05 UTC
[jira] [Updated] (SOLR-7820) 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
[ https://issues.apache.org/jira/browse/SOLR-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Potter updated SOLR-7820:
---------------------------------
Summary: 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 (was: IndexFetcher should delete the current index directory before downloading the new index when isFullCopyNeeded==true)
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org