I faced similar situation with solr cloud. http://lucene.472066.n3.nabble.com/Solr-Cloud-wiping-all-cores-when-restart-without-proper-zookeeper-directories-td4420598.html
Solr is deleting folders containing solr cores only any other folder is intact. On Fri, Apr 12, 2019 at 7:03 AM Shawn Heisey <apa...@elyograg.org> wrote: > 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 > -- *Thanks and Regards,* *Yogendra Kumar Soni*
