[
https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804677#comment-14804677
]
Jessica Cheng Mallet commented on SOLR-8069:
--------------------------------------------
Yes, I think this is definitely an improvement. I'm just not sure if it gets
everything covered. I suppose "we have near real confidence that we are the
leader and can do still do as we please" is probably good enough -- though I
haven't convinced myself yet through playing with complex scenarios of repeated
leadership changes -- thus I prefer the simple logic of "do this action only if
our zookeeper session state is exactly what it was when we decided to do it".
Anyhow, this is probably beyond the scope of this JIRA.
BTW, we tend to see this most when a "bad" query is issued (e.g. doing
non-cursorMark deep paging of page 50,000). Presumably it creates GC on each
replica it hits (since the request is retried) and a series of leadership
changes happen. Along with complication of GC pauses, the states are quite
difficult to reason through.
> 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
