[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14852717#comment-14852717
]
Mark Miller commented on SOLR-8069:
-----------------------------------
The difference is that this patch ensures we are still the leader when we get
the context - rather than blindly getting the current context.
bq. is somewhat diluted
I think it goes from being a large hole still to closed really. Someone might
have another idea for an improvement, but I don't see the scenario that really
sneaks by this yet.
bq. My question is if it's absolutely safe for this node to set the other node
in LiR simply because it's the leader now,
I think of course it is. It's valid for the leader and only the leader to set
anyone as down.
> 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
