[
https://issues.apache.org/jira/browse/SOLR-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14297991#comment-14297991
]
Mark Miller commented on SOLR-7034:
-----------------------------------
I filed SOLR-7065 to tackle the lesser change in my last comment.
> Consider allowing any node to become leader, regardless of their last
> published state.
> --------------------------------------------------------------------------------------
>
> Key: SOLR-7034
> URL: https://issues.apache.org/jira/browse/SOLR-7034
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: Trunk, 5.1
>
>
> Now that we allow a min replication param for updates, I think it's time to
> loosen this up. Currently, you can end up in a state where no one in a shard
> thinks they can be leader and you so do this fast ugly infinite loop trying
> to pick the leader.
> We should let anyone that is able to properly sync with the available
> replicas to become leader if that process succeeds.
> The previous strategy was to account for the case of not having enough
> replicas after a machine loss to ensure you don't lose the data. The idea was
> that you should stop the cluster to avoid losing data and repair and get all
> your replicas involved in a leadership election. Instead, we should favor
> carrying on, and those that want to ensure they don't lose data due to major
> replica loss should use the min replication update param.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
