[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804407#comment-14804407
]
Jessica Cheng Mallet commented on SOLR-8069:
--------------------------------------------
I still struggle with the safety of getting the ElectionContext from
electionContexts, because what's mapped there could change from under this
thread. What about if we write down the election node path (e.g.
238121947050958365-core_node2-n_0000000006) into the leader znode as a leader
props, so that whenever we're actually checking that we're the leader, we can
get that election node path back and do the zk multi checking for that
particular election node path?
Ugh, but then I guess lots of places are actually looking at the cluster
state's leader instead of the leader node. >_< Why are there separate places
for marking the leader? I don't know how to reason with the asynchronous nature
of cluster state's update wrt actual leader election...
> 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
