[
https://issues.apache.org/jira/browse/SOLR-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326525#comment-14326525
]
Mark Miller commented on SOLR-7117:
-----------------------------------
bq. In this should the check be only for node3 since node2 is already hosting
the replica. Unless "r2-4" meant node2 or node4
I think that '-' notation has been removed (it's probably just ignored now). I
think you used to specify the state that way. -4 prob would have been 'recovery
failed' state.
But yeah, looks like it should just be NODE3 with that not working anymore.
I'm guessing it's meant to be (now): "csr1R*r2Fsr3r4r5"
bq. Should we keep the property name "maxCoresPerNode"
Sounds reasonable to me.
> AutoAddReplicas should have a cluster wide property for controlling number of
> cores hosted on each node
> -------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7117
> URL: https://issues.apache.org/jira/browse/SOLR-7117
> Project: Solr
> Issue Type: Improvement
> Reporter: Varun Thacker
> Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-7117.patch, SOLR-7117.patch
>
>
> Currently when finding the best node to host the failed replicas, we respect
> the maxShardsPerNode property. This is not an ideal solution as it's a per
> collection property and we need a cluster wide property. Also using
> maxShardsPerNode can lead to unequal distribution of replicas across nodes.
> We should just let users use the CLUSTERPROP API to set the max number of
> cores to be hosted on each node and use that value while picking the node the
> replica will be hosted on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
