[ https://issues.apache.org/jira/browse/SOLR-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907370#comment-16907370 ]
Andrzej Bialecki commented on SOLR-13695: ------------------------------------------ Theoretically this should not happen... the index files of the sub-shards are hard-linked to the original shard BUT they are located in a different directory so deleting the parent shard should simply delete those directory entries (decrementing the number of existing links to the FS inodes). I'll try to reproduce this. The proposed fix is a temporary workaround at best because it defeats the whole point of {{splitMethod=link}}, which is to avoid rewriting segments. > SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss > --------------------------------------------------------------------------- > > Key: SOLR-13695 > URL: https://issues.apache.org/jira/browse/SOLR-13695 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Ishan Chattopadhyaya > Assignee: Ishan Chattopadhyaya > Priority: Critical > > One of my clients experienced data loss with the following sequence of > operations: > 1) SPLITSHARD with method as "link". > 2) DELETESHARD of the parent (inactive) shard. > 3) Query for documents in the subshards, seems like both subshards have 0 > documents. > Proposing a fix (after offline discussion with [~noble.paul]) based on > running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and > not letting DELETESHARD delete the data directory until the FORCEMERGE > operations finish. -- This message was sent by Atlassian JIRA (v7.6.14#76016) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org