I discussed this issue offline with David, and I'm now working on a code
change to make the preferredLeader to become the leader when we register a
replica.
The idea is, when we register a replica from Zookeeper, we check whether it
has the preferred leader flag. When true, we tell the cu
I found this existing issue:
https://issues.apache.org/jira/browse/SOLR-8238
I commented on it just now. Erick isn't around anymore but I'd appreciate
input from anyone using "preferredLeader".
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/d
he Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Feb 20, 2023 at 9:04 AM Bruno Roustant
wrote:
> After many tests and deployments, it appears the preferredLeader flag
> described in the RebalanceLeader command doc [1] is not useful.
> It is taken into accou
After many tests and deployments, it appears the preferredLeader flag
described in the RebalanceLeader command doc [1] is not useful.
It is taken into account only during the rebalance command. Afterwards, if
there is a leader election or some node restart, it is ignored.
Is this preferredLeader
shards.
I created a Jira issue SOLR-16438
<https://issues.apache.org/jira/browse/SOLR-16438> to support a
setPreferredLeaders on the split command (and to rebalance the leaders on
the split is complete).
Le ven. 23 sept. 2022 à 15:26, David Smiley a écrit :
> I'm not yet sure if pref
I'm not yet sure if preferredLeader is honored after a restart of the node
that has this state; though it'd be easy to see. I plan to observe this
empirically soon. If memory serves, I recall leader checks occur for each
replica on a node's start. One would think thi
;s choice of a leader isn't "sticky"; it can change and won't
> necessarily change back on its own if the original choice is eligible
> again. Setting "preferredLeader" on a replica and calling the
> REBALANCELEADERS API is how to make it sticky.[1]. Without this
SolrCloud's choice of a leader isn't "sticky"; it can change and won't
necessarily change back on its own if the original choice is eligible
again. Setting "preferredLeader" on a replica and calling the
REBALANCELEADERS API is how to make it sticky.[1]. With
