[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504889#comment-13504889
]
Yonik Seeley commented on SOLR-4114:
------------------------------------
bq. Well I see no reason to introduce (in the first step at least) a
maxShardsPerNode.
So that we don't lose functionality we currently have?
And I agree that it should be up to the user, hence the proposed parameter to
control it.
bq. Only potential problem is if his create request is run when not all Solr
servers are running, and in such case a maxShardsPerNode could help to stop the
creation process.
Exactly... there's the main use case.
Example: you have 24 servers and create a collection with 8 shards and a target
replication factor of 3... but one of the servers goes down in the meantime so
one shard has only 2 replicas. It's entirely reasonable for a user to want to
wait until that machine comes back up rather than doubling up on a different
node.
The other use case is the examples on http://wiki.apache.org/solr/SolrCloud
> Collection API: Allow multiple shards from one collection on the same Solr
> server
> ---------------------------------------------------------------------------------
>
> Key: SOLR-4114
> URL: https://issues.apache.org/jira/browse/SOLR-4114
> Project: Solr
> Issue Type: New Feature
> Components: multicore, SolrCloud
> Affects Versions: 4.0
> Environment: Solr 4.0.0 release
> Reporter: Per Steffensen
> Assignee: Per Steffensen
> Labels: collection-api, multicore, shard, shard-allocation
> Attachments: SOLR-4114.patch
>
>
> We should support running multiple shards from one collection on the same
> Solr server - the run a collection with 8 shards on a 4 Solr server cluster
> (each Solr server running 2 shards).
> Performance tests at our side has shown that this is a good idea, and it is
> also a good idea for easy elasticity later on - it is much easier to move an
> entire existing shards from one Solr server to another one that just joined
> the cluter than it is to split an exsiting shard among the Solr that used to
> run it and the new Solr.
> See dev mailing list discussion "Multiple shards for one collection on the
> same Solr server"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
