[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505541#comment-13505541
]
Jack Krupansky commented on SOLR-4114:
--------------------------------------
I certainly think of "replica" as a "copy of the ORIGINAL", which makes perfect
sense in a master with n-slaves configuration, but in a fully distributed
environment such as SolrCloud where the leader of a shard can vary over time
and updates are distributed to all nodes all of the time, there is no longer
the concept of an "original copy" of the data. If anything, the original data
is the source data on the wire before it gets instantiated on each node. No
node is truly the original.
The terminology has this difficulty that it is only partially shared between
the worlds of master/slave and the cloud. In master/slave, only the slaves are
replicas and the master is the original, while in cloud ALL nodes are replicas
since there are no originals. The "leader" is not a "master" copy of the data
in the sense of master/slave.
So, I guess I am semi-comfortable with replica referring to all instances of
the data, but we do need to be careful to highlight the distinction between how
the term replica is used in the world of master/slave vs. SolrCloud, especially
since many Cloud users will be migrating from the world of master/slave.
We also need to be careful not to refer to "leader and replicas" which implies
that a leader is not a replica!
> 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, 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
