[ https://issues.apache.org/jira/browse/SOLR-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14902021#comment-14902021 ]
Jessica Cheng Mallet commented on SOLR-8069: -------------------------------------------- bq. I don't think we really protect against such cases where there is only a single leader that can accept an update This is not the scenario I'm describing. If you have 3 replicas and one that was the leader gets partitioned off, one of the other 2 will get elected and they can carry on. However, during this transition time, because the cluster state update hasn't been completed or propagated through watches, the old leader can still get trailing updates from the client. In a normal case where the updates are successfully forwarded to all replicas, no one cares. But in this case, the old leader cannot forward the update to others (because it's partitioned off), so it should not reply success to the client because that would be wrong (it is not the leader and it does not have the right to tell the others to recover). > Ensure that only the valid ZooKeeper registered leader can put a replica into > Leader Initiated Recovery. > -------------------------------------------------------------------------------------------------------- > > Key: SOLR-8069 > URL: https://issues.apache.org/jira/browse/SOLR-8069 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Assignee: Mark Miller > Priority: Critical > 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