lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-3939) An empty or just replicated index cannot become the leader of a shard after a leader goes down.
Date Fri, 26 Oct 2012 14:33:13 GMT

    [ 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: yseeley@gmail.com):
    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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message