[ 
https://issues.apache.org/jira/browse/SOLR-11417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185154#comment-16185154
 ] 

Mark Miller commented on SOLR-11417:
------------------------------------

I'd have to look closer, but my first thought would be, we should make sure 
that if a replica comes up and attempts to be leader but fails due to a 
connection issue, it should make sure it can still successfully be a leader in 
a later attempt.

bq. will read stale data from ZK about current leader

We can always read stale data, so we have to make sure still operate correctly 
in the face of that.

bq. will fail recovery and stuck in recovering state

I guess the key question is, why are we stuck in recovering? What happens so 
that we cannot be leader when the ephemeral goes away? Do we overwrite the last 
active stat as not ACTIVE? In that case, it seems we should try and prevent 
that when a replica simply has connection problems with the leader vs failing a 
sync or something.


> Crashed leader's hanging emphemral will make restarting followers stuck in 
> recovering
> -------------------------------------------------------------------------------------
>
>                 Key: SOLR-11417
>                 URL: https://issues.apache.org/jira/browse/SOLR-11417
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 6.3
>            Reporter: Mano Kovacs
>         Attachments: SOLR-11417.png
>
>
> If replicas are starting up after leader crash and within the ZK session 
> timeout, replicas
> * will lose leader election due to hanging ephemerals
> * will read stale data from ZK about current leader
> * will fail recovery and stuck in recovering state
> If leader is down permanently (eg. hardware failure) and all replicas are 
> affected, shard will not come up (see also SOLR-7065).
> Tested on 6.3. See attached image for details.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to