I know this stuff can be confusing, but I think my statement is still true -
it uses the phrase "NEW primary shard" - the "promotion" of a shard can only
be to "replace" an existing primary shard, not to create a new and separate
partitioning of key values.
You left out the next sentence from my paragraph which covers the case you
mentioned: "Besides the simple fact that if a primary shard goes down, a
non-primary shard can be promoted to being a primary shard (“a replica shard
can be promoted to a primary shard if the primary fails.”)" In fact, I
literally quoted the passage from the ES doc which covers exactly the case
that I was accused of not covering("a replica shard can be promoted to a
primary shard if the primary fails")!
The point, my point, was simply that you can't create a "NEW" primary shard,
that shifts or rebalances keys from from one primary shard to a separate
primary shard - you can only "REPLACE" an existing primary shard.
One of the problems here is that the term "primary shard" refers to the
specific node and not to the logical data (partition of key values) that the
primary and "replica shards" for that primary shard manage.
AFAICT, there is not a specific term for the "partition" of key values that
a primary shard manages.
Again, just to be clear, I was referring to re-partitioning of the
assignment of key values to specific primary shards. In particular,
increasing the number of primary shards (number of partitions of key
values.)
Now, I am certainly not an expert in ES and my elaboration may still be
flawed, but I am endeavoring to ascertain what the facts are, either from
the doc or from others who are more expert in ES (I haven't gotten down to
the ES code, yet.)
-- Jack Krupansky
-----Original Message-----
From: Rafał Kuć
Sent: Saturday, July 06, 2013 3:05 AM
To: solr-user@lucene.apache.org
Subject: Re: Changing the number of shards?
Hello!
Just to be perfectly clear here - Solr has advantage over
ElasticSearch because it can split the live index. However, this
sentence from Jack's mail is not true:
"In other words, even though you can easily “add shards” on ES,
those are really just replicas of existing primary shards and cannot
be new primary shard"
The replicas can become new primary shards if something happens to a
primary shard - this is similar to what SolrCloud supports.
--
Regards,
Rafał Kuć
Sematext :: http://sematext.com/ :: Solr - Lucene - ElasticSearch
Correct.
ES currently does not let you change the number of shards after you've
created an Index (Collection in SolrCloud).
It does not let you split shards either. SolrCloud has an advantage
over ES around this at this point.
Otis
--
Solr & ElasticSearch Support -- http://sematext.com/
Performance Monitoring -- http://sematext.com/spm
On Fri, Jul 5, 2013 at 6:51 PM, Jack Krupansky <j...@basetechnology.com>
wrote:
According to the ElasticSearch glossary, “You cannot change the number of
primary shards in an index, once the index is created.” Really? Is that
true? (A “primary shard” is what Solr calls a shard, or slice.)
In other words, even though you can easily “add shards” on ES, those are
really just replicas of existing primary shards and cannot be new primary
shards – if I understand that statement correctly. Besides the simple
fact that if a primary shard goes down, a non-primary shard can be
promoted to being a primary shard (“a replica shard can be promoted to a
primary shard if the primary fails.”)
See:
http://www.elasticsearch.org/guide/reference/glossary/
My understanding is that with Solr you can do things like split shards
and change the number of shards per node. Is this an advantage that ES
does not offer?
Any ES experts want to comment?
-- Jack Krupansky
