Hi Vladimir, This is not an unreasonable requirement that the placement framework should support additional criteria :) just so far nobody contributed such a placement plugin.
Looking at AffinityPlacementPlugin I think it could be retrofitted to your need by customizing the WeightedNode / AffinityNode implementation to take into account the number of cores for this collection, e.g. in canAddReplica (you would need to pass the PlacementContet so that you can check the existing layout). Andrzej > On 24 Jul 2026, at 06:02, Vladimir Vyatkin via users <[email protected]> > wrote: > > Hi all, > > I'm looking for the current recommended way to cap how many replicas of a > collection can be placed on a single node, for the purpose of write-load > distribution rather than fault tolerance / georeplication. > > Situation: when a new, empty node is added to an existing cluster, the > default placement plugin — and MinimizeCores, which is driven by the same > kind of core-count weighting — end up preferring that node for essentially > every placement, since fewer existing cores/replicas always wins the > comparison. (Random doesn't have this problem, since it weights all nodes > equally and only uses randomness to break ties — but it also gives up any > load-aware placement in the process.) In a write-heavy setup this means > one freshly joined node absorbs most of the indexing load right after > joining, well before it should be trusted with that share of traffic, and > it can hit CPU saturation / thread starvation while the rest of the > cluster is comparatively idle. > > I know Solr 8.x had maxShardsPerNode for exactly this kind of capping, and > that it was removed in 9.0 (SOLR-12847) as part of the move to the > PlacementPlugin architecture, with the expectation that equivalent control > would be expressed through plugin config or collection properties. I've > gone through the current plugins (Simple, MinimizeCores, Random, Affinity) > and BALANCE_REPLICAS, and I don't see anything that lets me say "no more > than N replicas of this collection per node" up front, before the > imbalance happens: > > - AffinityPlacementFactory has withCollection, availability_zone / > spreadAcrossDomains, and node_type fencing, which help with placement > topology but don't cap replica count per node directly. > - BALANCE_REPLICAS (SOLR-16490 era) rebalances after the fact, which > works but requires the operator to notice the imbalance and trigger it > reactively rather than preventing it at placement time. > - createNodeSet / createNodeSet=EMPTY only affect a single CREATE call > and don't constrain future ADDREPLICA/SPLITSHARD placements onto the > same node. > > So, two questions: > > 1. Is there an existing, supported way to express "at most N replicas of > collection X per node" that I've missed, short of writing a fully > custom PlacementPlugin? > > 2. If not, is a per-node replica cap in this vein still considered > in-scope for the placement framework, or was it deliberately left out > because it's expected to be handled by BALANCE_REPLICAS / operational > tooling instead? > > I want to stress this is specifically about load distribution across > otherwise-equal nodes (spreading write/query load evenly as a collection > grows and as nodes join/leave), not about failure-domain separation — > Affinity's withCollection/spreadAcrossDomains already cover the > georeplication / fault-domain angle well. > > If there's no simple existing path, I have some groundwork done already > and I'm planning to file a JIRA and propose a PR for an opt-in per-node > replica cap along these lines. Wanted to check here first in case I'm > missing a cleaner existing mechanism, or in case this was already > discussed and rejected for a reason I should know about before proposing > it. > > -- > Thanks, > Vladimir Vyatkin
