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

Colvin Cowie commented on SOLR-13396:
-------------------------------------

I couldn't wait for something to be done / agreement to be reached on what to 
do with this issue, so the workaround I used in my product was to subclass the 
{{org.apache.solr.core.CoreContainer}} and override the {{unload(String, 
boolean, boolean, boolean)}} method so that it doesn't delete a core in this 
scenario. (I also subclass {{org.apache.solr.servlet.SolrDispatchFilter}} 
[which is specified in the web.xml] and override {{createCoreContainer(Path, 
Properties)}} which is where I call my overridden core container from, which 
means modifying the ).

 

It's almost 3 years since this was raised. If nothing else, could we at least 
have a flag that can be used to disable this destructive by default behaviour 
through the solr.in?

> SolrCloud will delete the core data for any core that is not referenced in 
> the clusterstate
> -------------------------------------------------------------------------------------------
>
>                 Key: SOLR-13396
>                 URL: https://issues.apache.org/jira/browse/SOLR-13396
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 7.3.1, 8.0
>            Reporter: Shawn Heisey
>            Priority: Major
>
> SOLR-12066 is an improvement designed to delete core data for replicas that 
> were deleted while the node was down -- better cleanup.
> In practice, that change causes SolrCloud to delete all core data for cores 
> that are not referenced in the ZK clusterstate.  If all the ZK data gets 
> deleted or the Solr instance is pointed at a ZK ensemble with no data, it 
> will proceed to delete all of the cores in the solr home, with no possibility 
> of recovery.
> I do not think that Solr should ever delete core data unless an explicit 
> DELETE action has been made and the node is operational at the time of the 
> request.  If a core exists during startup that cannot be found in the ZK 
> clusterstate, it should be ignored (not started) and a helpful message should 
> be logged.  I think that message should probably be at WARN so that it shows 
> up in the admin UI logging tab with default settings.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to