[
https://issues.apache.org/jira/browse/SOLR-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484683#comment-13484683
]
Yonik Seeley edited comment on SOLR-3939 at 10/26/12 2:32 PM:
--------------------------------------------------------------
bq. Isn't that what capturing the starting versions is all about?
For a node starting up, yeah. For a leader syncing to someone else - I don't
think it should matter.
edit: OK - I think I got what you're saying now - if the new node coming up did
have an extra doc, then the only way to guarantee the leader pick it up would
be if not too many updates came in for either. We could require that a sync
from the leader to the replica have the list of recent versions overlap enough
(else the replica would be forced to replicate), but as you say... if updates
are coming in fast enough (and that is prob pretty slow) you're going to force
a replication anyway.
bq. but if you want to peer sync from the leader to a replica that is coming
back up, if updates are coming in, you are going to force a replication anyway.
If updates were coming in fast enough during the "bounce"... I guess so.
was (Author: [email protected]):
bq. Isn't that what capturing the starting versions is all about?
For a node starting up, yeah. For a leader syncing to someone else - I don't
think it should matter.
bq. but if you want to peer sync from the leader to a replica that is coming
back up, if updates are coming in, you are going to force a replication anyway.
If updates were coming in fast enough during the "bounce"... I guess so.
> 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: [email protected]
For additional commands, e-mail: [email protected]
