[
https://issues.apache.org/jira/browse/SOLR-12999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692096#comment-16692096
]
Michael Braun commented on SOLR-12999:
--------------------------------------
On my old project we forked IndexFetcher to do something similar - when full
replication was called for (so we'd be deleting every single file once it was
done), we pointed the index to a newly-created dummy directory and made sure
the Searcher was off the existing one before a cleanup was triggered on the
original index directory, which would cause the underlying now-unneeded files
to be deleted.
[~jason.j.b...@gmail.com] can probably add more to this.
> Index replication could delete segments first
> ---------------------------------------------
>
> Key: SOLR-12999
> URL: https://issues.apache.org/jira/browse/SOLR-12999
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java)
> Reporter: David Smiley
> Priority: Major
>
> Index replication could optionally delete files that it knows will not be
> needed _first_. This would reduce disk capacity requirements of Solr, and it
> would reduce some disk fragmentation when space get tight.
> Solr (IndexFetcher) already grabs the remote file list, and it could see
> which files it has locally, then delete the others. Today it asks Lucene to
> {{deleteUnusedFiles}} at the end. This new mode would only be useful if
> there is no SolrIndexSearcher open, since it would prevent the removal of
> files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
