Description
Context:
We have a SolrCloud deployment managed by the Solr Operator. Our collection initially has 3 replicas, and the Solr cluster consists of 6 Solr pods.
When we add 2 more Solr pods , the Solr Operator automatically rebalances the collection's replicas across all available pods.
This behavior appears to be controlled by the following configuration in the SolrCloud CRD:
spec:
scaling:
vacatePodsOnScaleDown: true # Default: true
populatePodsOnScaleUp: true # Default: true
We have not explicitly set these fields, so the default values are applied, resulting in automatic rebalancing during scale-up.
Observation:
Looking at the Solr Operator code, we noticed that the operator uses Solr’s internal replica balancing API:
rebalanceRequest := &solr_api.SolrRebalanceRequest{
WaitForFinalState: true,
Async: requestId,
}
rebalanceResponse := &solr_api.SolrAsyncResponse{}
err = solr_api.CallCollectionsApiV2(ctx, solrCloud, "POST", "/api/cluster/replicas/balance", nil, rebalanceRequest, rebalanceResponse)
The body of POST request corresponds to this struct:
type SolrRebalanceRequest struct {
Nodes []string `json:"nodes,omitempty"`
WaitForFinalState bool `json:"waitForFinalState,omitempty"`
Async string `json:"async,omitempty"`
}
The Nodes field is not set in the request. As a result, Solr rebalances replicas across all available nodes in the cluster.
Ask:
Is there a way to constrain rebalancing to only the newly added nodes (or to avoid unnecessary redistribution of existing replicas), so that the collection retains the same number of replicas after scaling up?
The goal is to:
- Maintain the replica count per collection after scaling.
- Avoid potentially unnecessary movement of replicas if rebalancing is not explicitly desired.
If not currently supported, would support for a more fine-grained control (e.g., specifying Nodes in the rebalance request) be a feasible enhancement?