On 4/11/2019 6:44 PM, Koen De Groote wrote:
I gathered a solr log from 7.6.0 at TRACE level.
Then I replicated the experiment with 6.6.5 and with that version, the
directories were not deleted. Log also included.
The audit log is from solr7. The deletes start at 01:51:48, which
translates to 23:51:48 UTC, which you'll be able to find in the solr7 log.
The directories were deleted, you can see the calls in the audit logs, but
I can't identify in the solr7 log if a delete is being called somewhere.
Could be that it's not logged at all.
I think that SOLR-12066 is indeed the cause of the problem. The intent
with that issue was to eliminate cores that had been deleted while the
node was down ... but in practice, it serves to delete any core data
that isn't in the clusterstate.
It's certainly true that a well-designed ZooKeeper ensemble with a
minimum of three nodes is extremely unlikely to lose its database, but
somebody might use the wrong ZKHOST setting and accidentally point their
SolrCloud install at an ensemble that exists but has no data. Problems
with a chroot are most likely, I think -- forgetting to add the chroot
seems like a good way to cause this issue.
I have opened an issue for the problem.
https://issues.apache.org/jira/browse/SOLR-13396
Thanks,
Shawn
