[
https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849860#comment-16849860
]
Koen De Groote commented on SOLR-13396:
---------------------------------------
In the mean time, while this is awaiting being picked up or being assigned, I'm
working on a script that contacts zkCli.sh, queries it for its directories and
checks if the one I want is in there with the underlying tree that I expect it
to have.
I guess that should offer some protection in case not everything is detected,
in which case I can stop the deploy before solr starts.
But I'm wondering about cases where zookeeper crashes and restarts, and the
solr reconnects to it and it offers an empty list. What happens then?
Or will zookeeper first reconnect with all the other zookeepers in its
ensemble, sync configs and then open itself up for connections?
What if it loses its config of being part of an ensemble and just opens itself
up, empty?
> 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
> Security Level: Public(Default Security Level. Issues are Public)
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
