It should also be possible to set preferred leaders during shard split. Currently, shard split always keeps the current host as the leader of the sub-shards. And if we split again sub-shards, this can lead to a very unbalanced situation where the same host becomes the leader for a whole set of 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 <dsmi...@apache.org> a écrit : > 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 this would respect > preferredLeader already? If it doesn't, then the solution, I think, would > be to fix it so that it does respect it? We'll see. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Sep 22, 2022 at 7:02 AM Jan Høydahl <jan....@cominvent.com> wrote: > > > We have the new Replica Placement API, which can react to various events > > like nodeUp, nodeDown etc. > > Would it make sense to auto rebalance leaders after a certain delay after > > the last nodeDown/Up event occurred? > > > > Jan > > > > > 22. sep. 2022 kl. 05:23 skrev David Smiley <dsmi...@apache.org>: > > > > > > 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]. Without this, a > > rolling > > > restart (common-place in a cloud-native world?) will leave the last > node > > > without any leaders. That can lead to a resource usage imbalance, > > > particularly with TLOG due to the higher differentiation of activity a > > > leader does vs a non-leader. Make sense? > > > > > > Would it make sense for collection creation to have a > setPreferredLeader > > > option or some-such boolean name? Or just let the caller/client do so > if > > > it pleases, and maybe mention this as advice in the reference guide? > Or > > > just do this by default for TLOG collection creation... although I > wonder > > > if it'd interfere with how some users manage their clusters? > > > > > > [1] > > > > > > https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#rebalanceleaders > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > >
