[
https://issues.apache.org/jira/browse/SOLR-9836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15829176#comment-15829176
]
ASF subversion and git services commented on SOLR-9836:
-------------------------------------------------------
Commit 59d7bc5ede7cf4d50b5efb79b31bc0343d6f10dc in lucene-solr's branch
refs/heads/branch_6x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59d7bc5 ]
SOLR-9836: Add ability to recover from leader when index corruption is detected
on SolrCore creation.
# Conflicts:
# solr/CHANGES.txt
# solr/core/src/java/org/apache/solr/core/CoreContainer.java
> Add more graceful recovery steps when failing to create SolrCore
> ----------------------------------------------------------------
>
> Key: SOLR-9836
> URL: https://issues.apache.org/jira/browse/SOLR-9836
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: Mike Drob
> Assignee: Mark Miller
> Attachments: SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch,
> SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch, SOLR-9836.patch
>
>
> I have seen several cases where there is a zero-length segments_n file. We
> haven't identified the root cause of these issues (possibly a poorly timed
> crash during replication?) but if there is another node available then Solr
> should be able to recover from this situation. Currently, we log and give up
> on loading that core, leaving the user to manually intervene.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
