[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14901817#comment-14901817
]
Mark Miller commented on SOLR-8069:
-----------------------------------
bq. if it's a node that was a leader but has just been network-partitioned off
(but clusterstate change hasn't been made since it's asynchronous) and wasn't
able to actually forward the request to the real leader.
I don't think we really protect against such cases where there is only a single
leader that can accept an update because all its replicas go bad and then it
goes away but the replicas come back. That is what min replication factor on
the request is meant to handle. For full data promises, you want to use it - an
achieved replication factor of 1 is not going to be fault tolerant.
> Ensure that only the valid ZooKeeper registered leader can put a replica into
> Leader Initiated Recovery.
> --------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Critical
> Attachments: SOLR-8069.patch, SOLR-8069.patch
>
>
> I've seen this twice now. Need to work on a test.
> When some issues hit all the replicas at once, you can end up in a situation
> where the rightful leader was put or put itself into LIR. Even on restart,
> this rightful leader won't take leadership and you have to manually clear the
> LIR nodes.
> It seems that if all the replicas participate in election on startup, LIR
> should just be cleared.
--
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
