[ 
https://issues.apache.org/jira/browse/SOLR-15055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17262452#comment-17262452
 ] 

Andrzej Bialecki commented on SOLR-15055:
-----------------------------------------

[~mdrob] in 8x `maxShardsPerNode` was totally broken and didn't do what you 
would expect it to. It didn't actually affect the placement at all - it was 
only a crude initial check to see if the total number of replicas was larger 
than the number of nodes x maxShardsPerNode, regardless of where the placements 
would be. That's why almost all tests would set it to -1 or a large number, 
simply to bypass this check.

> Re-implement 'withCollection' and 'maxShardsPerNode'
> ----------------------------------------------------
>
>                 Key: SOLR-15055
>                 URL: https://issues.apache.org/jira/browse/SOLR-15055
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Andrzej Bialecki
>            Assignee: Andrzej Bialecki
>            Priority: Major
>          Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> Solr 8x replica placement provided two settings that are very useful in 
> certain scenarios:
> * {{withCollection}} constraint specified that replicas should be placed on 
> the same nodes where replicas of another collection are located. In the 8x 
> implementation this was limited in practice to co-locating single-shard 
> secondary collections used for joins or other lookups from the main 
> collection (which could be multi-sharded).
> * {{maxShardsPerNode}} - this constraint specified the maximum number of 
> replicas per shard that can be placed on the same node. In most scenarios 
> this was set to 1 in order to ensure fault-tolerance (ie. at most 1 replica 
> of any given shard would be placed on any given node). Changing this 
> constraint to values > 1 would reduce fault-tolerance but may be desired in 
> test setups or as a temporary relief measure.
>  
> Both these constraints are collection-specific so they should be configured 
> e.g. as collection properties.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to