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

David Smiley commented on SOLR-12999:
-------------------------------------

I think it'd be a shame to not retain the optimization.  I disagree with "data 
loss" -- it's up to the leader election / "shard terms" to deem who is leader 
eligible.  A replica that is about to pull the whole index from another node 
isn't leader eligible (right?).  The implementation could take a step to 
guarantee it's not marked as such (shard terms manipulation).  But it's even 
more of a shame that the implementation is buggy/unreliable/untested.  So I 
very much sympathize with removing it on that grounds.  I leave it to you.

> Index replication could delete segments first
> ---------------------------------------------
>
>                 Key: SOLR-12999
>                 URL: https://issues.apache.org/jira/browse/SOLR-12999
>             Project: Solr
>          Issue Type: Improvement
>          Components: replication (java)
>            Reporter: David Smiley
>            Assignee: Noble Paul
>            Priority: Major
>             Fix For: 8.1
>
>         Attachments: SOLR-12999.patch, SOLR-12999.patch
>
>
> 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 probably only be 
> useful if there is no SolrIndexSearcher open, since it would prevent the 
> removal of files.
> The motivating scenario is a SolrCloud replica that is going into full 
> recovery.  It ought to not be fielding searches.  The code changes would not 
> depend on SolrCloud though.
> This option would have some danger the user should be aware of.  If the 
> replication fails, leaving the local files incomplete/corrupt, the only 
> recourse is to try full replication again.  You can't just give up and field 
> queries.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to