You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Cao Manh Dat (JIRA)" <ji...@apache.org> on 2018/03/05 09:19:00 UTC
[jira] [Resolved] (SOLR-7034) Consider allowing any node to become
leader, regardless of their last published state.
[ https://issues.apache.org/jira/browse/SOLR-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cao Manh Dat resolved SOLR-7034.
--------------------------------
Resolution: Fixed
Assignee: Cao Manh Dat (was: Mark Miller)
Fix Version/s: (was: 6.0)
(was: 5.2)
7.3
master (8.0)
Fixed by SOLR-12011
> 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: Cao Manh Dat
> Priority: Major
> Fix For: master (8.0), 7.3
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org