[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804438#comment-14804438
]
Jessica Cheng Mallet commented on SOLR-8069:
--------------------------------------------
Actually, thinking about it -- why do we have the leader property in cluster
state at all? If it's simply to publish leadership to solrj, it seems that on
the server-side we should still use the leader znode as the "source of truth"
so that we can have guarantees of consistent view along with the zk
transactions. If solrj's view falls behind due to the asynchronous nature of
having the Overseer update the state, at least on the server side we can check
the leader znode.
Any historical reason why leadership information is in two places?
> 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: [email protected]
For additional commands, e-mail: [email protected]
