[
https://issues.apache.org/jira/browse/SOLR-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483567#comment-13483567
]
Yonik Seeley commented on SOLR-3939:
------------------------------------
Trying to think if this could happen when there are versions too... say that
instead of having no versions, we just have old versions from before we did the
replication. This may argue for somehow marking the start of a replication in
the transaction log and then never retrieving versions older than that.
> An empty or just replicated index cannot become the leader of a shard after a
> leader goes down.
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-3939
> URL: https://issues.apache.org/jira/browse/SOLR-3939
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0-BETA, 4.0
> Reporter: Joel Bernstein
> Assignee: Mark Miller
> Priority: Critical
> Labels: 4.0.1_Candidate
> Fix For: 4.1, 5.0
>
> Attachments: cloud2.log, cloud.log, SOLR-3939.patch, SOLR-3939.patch
>
>
> When a leader core is unloaded using the core admin api, the followers in the
> shard go into recovery but do not come out. Leader election doesn't take
> place and the shard goes down.
> This effects the ability to move a micro-shard from one Solr instance to
> another Solr instance.
> The problem does not occur 100% of the time but a large % of the time.
> To setup a test, startup Solr Cloud with a single shard. Add cores to that
> shard as replicas using core admin. Then unload the leader core using core
> admin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
