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
