[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14876879#comment-14876879
]
Jessica Cheng Mallet commented on SOLR-8069:
--------------------------------------------
bq. I think it does. A leader can do this. It doesn't matter if it had a valid
reason to do it or not.
If you believe that this is true, I do agree that your patch will accomplish
the check that at the moment you're setting someone else down, you're the
leader. If we're going with this policy though, I think if at this moment it
realizes that it's not the leader, it should actually fail the request because
it shouldn't accept it on the real leader's behalf. E.g. 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.
> Leader Initiated Recovery can put the replica with the latest data into LIR
> and a shard will have no leader even on restart.
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8069
> URL: https://issues.apache.org/jira/browse/SOLR-8069
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> 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
