And based on the previous explanation there is never a "copy of a shard". A
shard represents and contains only replicas for itself, replicas being copies of cores
within the shard.
<br><br><br>------- Original Message -------
On 1/3/2013 11:58 AM Walter Underwood wrote:<br>A "factor" is multiplied, so
multiplying the leader by a replicationFactor of 1 means you have exactly one copy of that
shard.
<br>
<br>I think that recycling the term "replication" within Solr was confusing, but it is a bit late to change that.
<br>
<br>wunder
<br>
<br>On Jan 3, 2013, at 7:33 AM, Mark Miller wrote:
<br>
<br>> This has pretty much become the standard across other distributed systems
and in the literat…err…books.
<br>>
<br>> I first implemented it as you mention you'd like, but Yonik correctly pointed out that we were going against the grain.
<br>>
<br>> - Mark
<br>>
<br>> On Jan 3, 2013, at 10:01 AM, Per Steffensen <st...@designware.dk> wrote:
<br>>
<br>>> For the same reasons that "Replica" shouldnt be called "Replica" (it requires to long an explanation to agree that it is an ok name), "replicationFactor" shouldnt be called "replicationFactor" and long as it referes to the TOTAL number of cores you get for your "Shard". "replicationFactor" would be an ok name if replicationFactor=0 meant one core, replicationFactor=1 meant two cores etc., but as long as replicationFactor=1 means one core, replicationFactor=2 means two cores, it is bad naming (you will not get any replication with replicationFactor=1 - WTF!?!?). If we want to insist that you specify the total number of cores at least use "replicaPerShard" instead of "replicationFactor", or even better rename "Replica" to "Shard-instance" and use "instancesPerShard" instead of "replicationFactor".
<br>>>
<br>>> Regards, Per Steffensen
<br>>>
<br>>> On 1/3/13 3:52 PM, Per Steffensen wrote:
<br>>>> Hi
<br>>>>
<br>>>> Here is my version - do not believe the explanations have been very clear
<br>>>>
<br>>>> We have the following concepts (here I will try to explain what each the concept cover without naming it - its hard)
<br>>>> 1) Machines (virtual or physical) running Solr server JVMs (one machine
can run several Solr server JVMs if you like)
<br>>>> 2) Solr server JVMs
<br>>>> 3) Logical "stores" where you can add/update/delete data-instances (closest to
"logical" tables in RDBMS)
<br>>>> 4) Logical "slices" of a store (closest to non-overlapping "logical" sets of rows
for the "logical" table in a RDBMS)
<br>>>> 5) Physical instances of "slices" (a physical (disk/memory) instance of the a "logical"
slice). This is where data actually goes on disk - the logical "stores" and "slices" above are just non-physical
concepts
<br>>>>
<br>>>> Terminology
<br>>>> 1) Believe we have no name for this (except of course machine :-) ), even though Jack claims that this is
called a "node". Maybe sometimes it is called a "node", but I believe "node" is more often used to refer
to a "Solr server JVM".
<br>>>> 2) "Node"
<br>>>> 3) "Collection"
<br>>>> 4) "Shard". Used to be called "Slice" but I believe now it is officially called
"Shard". I agree with that change, because I believe most of the industry also uses the term "Shard" for this
logical/non-physical concept - just needs to be reflected it across documentation and code
<br>>>> 5) "Replica". Used to be called "Shard" but I believe now it is officially called "Replica". I certainly do not agree with the name
"Replica", because it suggests that it is a copy of an "original", but it isnt. I would prefer "Shard-instance" here, to avoid the confusion. I understand that you can argue
(if you argue long enough) that "Replica" is a fine name, but you really need the explanation to understand why "Replica" can be defended as the name for this. Is is not immediately
obvious what this is as long as it is called "Replica". A "Replica" is basically a Solr Cloud managed Core and behind every Replica/Core lives a physical Lucene index. So Replica=Core)
contains/maintains Lucene index behind the scenes. The term "Replica" also needs to be reflected across documentation and code.
<br>>>>
<br>>>> Regards, Per Steffensen
<br>>>
<br>>
<br>
<br>--
<br>Walter Underwood
<br>wun...@wunderwood.org
<br>
<br>
<br>
<br>
