[
https://issues.apache.org/jira/browse/SOLR-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855119#comment-16855119
]
Koen De Groote commented on SOLR-13396:
---------------------------------------
Just did some testing:
I created a `/solr` directory in zookeeper and put some test data in it.
If I delete the `version-2` folder, the solr data directories remain in place.
When restarting the containers, nothing changes. In fact, solr refuses to
connect with zookeeper, with messages like this:
2019-06-03 22:18:08.648 WARN (qtp574568002-28) [ ] o.e.j.s.HttpChannel /solr/
javax.servlet.ServletException: javax.servlet.UnavailableException: Error
processing the request. CoreContainer is either not initialized or shutting
down.
And
2019-06-03 22:04:10.654 ERROR
(OverseerCollectionConfigSetProcessor-72057939225149443-localhost:8983_solr-n_0000000001)
[ ] o.a.s.c.OverseerTaskProcessor
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss for /overseer_elect/leader
The problem of data directories being deleted really only occurs when I
re-create the /solr chroot... which is then empty. They don't contain the data
of the old ZK. So when I then restart solr, it connects to ZK, finds what it's
looking for, namely `/solr`, sees that it is empty, and proceeds to make it so
that the data on disk for solr is identical to what it found. In this case:
empty.
I don't see how that problem can be fixed. Would really like some feedback on
that.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
