[
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: [email protected]
For additional commands, e-mail: [email protected]
