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 > >
