My first question would “why do you think this is important?”. The additional burden a leader has is quite small and is only present when indexing. Leaders have no role in processing queries.
So unless you have, say, on the order of 100 leaders on a single Solr instance _and_ are indexing heavily, I’d be surprised if you notice any difference between that and having leaders evenly distributed. I would _strongly_ urge you, BTW, to have legacyCloud set to false. That setting will totally go away at some point, so adjusting sooner rather than later is probably a good idea. Bottom line. I’d recommend just using the defaults (including legacyCloud) and not worrying about distributing the leader role unless and until you can prove that having unbalanced leaders is really having a performance impact. In my experience, 95% of the time people spend time trying to manage which nodes are leaders the effort is wasted. Best, Erick > On Apr 20, 2019, at 2:45 PM, Raveendra Yerraguntla > <raveend...@yahoo.com.INVALID> wrote: > > All, > We are upgrading from solr 5.4 to solr 7.6. In 5.4 each solr process based on > the core.properties (shard value assigned) will be joining as either leader > or replica based on the sequence of start. > By following the same procedure in 7.6 the initial leader node solr process > is replaced with later started solr. Also in the process core is not loaded > in the later solr process (which is supposed to be replica). > To have the compatibility , the legacyCloud property is set as true in the > clustereprops.json > Question: .With replica type is NRT to keep the transition smooth.How to add > later started solr process as replicas in 7.6, without interfering the leader > election process? > Appreciate any pointers in understanding and resolving the issue. > ThanksRavi
