[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804446#comment-14804446
]
Mark Miller commented on SOLR-8069:
-----------------------------------
bq. I still struggle with the safety of getting the ElectionContext from
electionContexts, because what's mapped there could change from under this
thread.
That is why I check before and after we get the context that we locally think
we are the leader. The idea is, if we locally are connected to zk and think we
are leader before and after getting the latest context, we have near real
confidence that we are the leader and can do still do as we please.
There really is nothing tricky about the leader being advertised in
clusterstate - it's simply slightly stale state that is updated by Overseer. I
don't see how it complicates an approach to this?
> 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
>
>
> 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
