[
https://issues.apache.org/jira/browse/SOLR-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696260#comment-17696260
]
David Smiley commented on SOLR-8238:
------------------------------------
bq. What if the node is out of commission permanently?
Delete the replicas (logically; physically they are already gone); add
"preferredLeader" to other replicas as appropriate.
bq. How long should one wait ...
Don't! It's a best-effort thing, not a guarantee. Initiate async; don't
block. Maybe do in a limited pool so as to not do too many at once.
bq. Assume that a node that has preferredleader set for some reason wasn't the
leader at shutdown, then how do you insure that can become the leader without
data loss?
Eligibility for leadership requires a replica to be up-to-date which is
governed by the ZK Shard Terms mechanism that Dat added -- solid engineering
there! preferredLeaders is really unrelated; _it cannot make someone a leader
that isn't otherwise ineligible!_. Thus no data loss risks in this matter.
Me or one of my esteemed colleagues is likely to re-open this with something.
> Make Solr respect preferredLeader at startup
> --------------------------------------------
>
> Key: SOLR-8238
> URL: https://issues.apache.org/jira/browse/SOLR-8238
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 5.2.1
> Reporter: Peter Morgan
> Priority: Minor
>
> After setting preferredLeader property, noticed that upon restarting leaders
> revert to wherever they were previously running before REBALANCE was called.
> I would expect the preferredLeader to influence the startup election, but it
> appears it is not observed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
