[ https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944490#comment-16944490 ]
Colvin Cowie commented on SOLR-13396: ------------------------------------- ZkStateReader in solrj has something similar, checking that theĀ clusterstate.json exists (https://github.com/apache/lucene-solr/blob/b51013a10b5acd603ae934fa56714ffb7eb3641b/solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1093) > 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.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org