[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505471#comment-13505471
]
Yonik Seeley commented on SOLR-4114:
------------------------------------
bq. Ok, its just than the replicationFactor you specify in your request is the
other thing.
Hmmm, you're right:
"Note: replicationFactor defines the maximum number of replicas created in
addition to the leader from amongst the nodes currently running"
That's not consistent with the original definition
(http://wiki.apache.org/solr/NewSolrCloudDesign), the way the state is
represented in clusterstate, or the way others use the term such as in
hbase/HDFS, cassandra, oracle, etc. The important part is how many times the
data is stored (the replication factor), and things like leaders are more of an
implementation detail.
Luckily we don't yet store this in the cluster, so there's no back compat issue
with existing clusters. There's only a change when creating a new cluster, but
that seems relatively minor. Given that, I'd lean toward changing this
parameter to be in line with common usage.
Per: this is unrelated to your patch of course - it just happened to come up
here.
> 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
