[
https://issues.apache.org/jira/browse/SOLR-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696219#comment-17696219
]
Erick Erickson commented on SOLR-8238:
--------------------------------------
Yes, I was describing the background for preferred and rebalance, kinda got off
on a tangent.
As for this particular JIRA, the implication is that preferredleader should be
respected on restart. There was a lot of angst expressed in discussions and
JIRAs that had the underlying assumption that leadership needed to be spread
evenly or Bad Things Happened, even in smaller installations.
The existence of preferredleaders and rebalanceleaders certainly fed that
angst, I can see people thinking "why would these commands even exist
otherwise?". The answer is that these commands were put in (by me) to address a
problem with a cluster that was an extreme outlier in terms of the number of
shards that could have a replica hosted on a single machine, thus possibly
having a totally unreasonable number of leaders on that machine, enough to
affect performance noticeably.
Once you start down the path of trying to honor preferred leaders on startup,
things get hairy very quickly. Off the top of my head:
* What if the node is out of commission permanently?
* How long should one wait for a node to come up and assume (preferred)
leadership, and how would that affect very large cluster startup? It could add
hours and hours and hours if we waited even 60 seconds for the node to come up
and assume leadership for a particular shard, assuming many, many, many shards.
* 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?
* etc.
So my reason for "won't fix" was that in those rare cases where too many
leaders was a noticeable problem, preferredleader and rebalanceleaders existed
to address it at the discretion of sysops and should be used in those
situations rather than penalize everyone else, both in bugs sure to be
introduced and performance. I mean it's not like we had any problem with leader
election historically ;)...
Now, all that said, this was some years ago, when we were just beginning to get
into really large clusters. Whether all this makes sense now is an open
question.
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
