[
https://issues.apache.org/jira/browse/SOLR-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-7034:
-------------------------------
Attachment: SOLR-7034.patch
> 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
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Major
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7034.patch, SOLR-7034.patch, SOLR-7034.patch
>
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
