[
https://issues.apache.org/jira/browse/SOLR-15055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268615#comment-17268615
]
Andrzej Bialecki commented on SOLR-15055:
-----------------------------------------
[~ichattopadhyaya] verification of co-location at query time has several
drawbacks:
* it doesn't guarantee that the request will be handled at all, maybe never
* it puts the burden on the operator to maintain the colocation, without any
help from Solr. ADDREPLICAs for the primary collection may put replicas
anywhere and the operator then has to discover the placement and "chase" it
with the secondary replicas - and even then this opens a time window when
requests can be denied
Regarding the complexity of the PR:
* please note that some of the unrelated files are modified because I moved
{{PROPERTY_PREFIX}} to a better location.
* the actual modifications in collection Cmd-s are minimal - it's true that I
did some refactoring in {{DeleteReplicaCmd}} for clarity but the substantial
changes are just a few lines long.
* the changes in the {{placement.*}} package are to enable placement plugins
to have some control of operations other than ADDREPLICA. Sooner or later this
functionality would be needed anyway.
So, if you disregard the added functionality in the placement plugins, the
overall changes to support {{withCollection}} are limited just to the
{{AffinityPlacementFactory}} plugin implementation, and the rest of Solr code
has no idea that this functionality is supported. IMHO this is a good level of
separation from core and encapsulation of optional capability.
> 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: 8h 40m
> 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
