[
https://issues.apache.org/jira/browse/SOLR-12999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693648#comment-16693648
]
Erick Erickson commented on SOLR-12999:
---------------------------------------
[~dsmiley] Ah, ok. That makes sense. Deleting them first since you can't search
anyway seems safe enough.
[~mbraun688]
bq. The other use case for this is if you're using more than 50% hard drive,
copying index files could result in going out of disk
That's the dangerous case unless, as David indicates, the replica is never
going to serve queries anyway. Say replication deletes segments, then _for any
reason_, the sync fails to complete. No new searchers can be opened. Ever.
Worse, if this cascaded through multiple replicas you could lose data.
You could refuse to start to replicate if the total size of the segments you
_knew_ you had to copy exceeded your available disk space (plus some fudge
factor maybe), but there'd still be race conditions where more than one
core/replica decided to do a full sync.
> 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
