[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505001#comment-13505001 ]
Yonik Seeley commented on SOLR-4114: ------------------------------------ bq. > So that we don't lose functionality we currently have? bq. So now you care about backwards compatibility? I was speaking specifically about functionality, not back compatibility. bq. With your current solution there will be no "waiting until that machine comes back up". You will just end up with 8 slices, where 7 of them have 2 replica, and the last only have 1 replica. Correct. When I said "it's entirely reasonable for a user to want to wait", I meant wait to create the additional replica for one shard, not wait to create the whole collection. Although I guess it might be useful to be able to fail collection creation if certain specified constraints aren't met (including a min replication factor). As far as terminology, when I say replicationFactor of 3, I mean 3 copies of the data. I also count the leader as a replica of a shard (which is logical). It follows from the clusterstate.json, which lists all "replicas" for a shard and one of them just has a flag indicating it's the leader. This also makes it easier to talk about a shard having 0 replicas (meaning there is not even a leader). > 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