On 9/30/2011 12:26 PM, Pulkit Singhal wrote:
> SOLR-2355 is definitely a step in the right direction but something I
> would like to get clarified:
Questions about SOLR-2355 are best asked in SOLR-2355 :)
> b) Does this basic implementation distribute across shards or across
> cores?
>From a bri
Thanks Pulkit!
I'd actually been meaning to add the post.jar commands needed to index a doc to
each shard to the wiki. Waiting till I streamline a few things though.
- Mark
On Sep 30, 2011, at 12:35 PM, Pulkit Singhal wrote:
> BTW I update the wiki with the following, hope it keeps it simpel f
BTW I update the wiki with the following, hope it keeps it simpel for
others starting out:
Example B: Simple two shard cluster with shard replicas
Note: This setup leverages copy/paste to setup 2 cores per shard and
distributed searches validate a succesful completion of this
example/exercise. But
SOLR-2355 is definitely a step in the right direction but something I
would like to get clarified:
a) There were some fixes to it that went on the 3.4 & 3.5 branch based
on the comments section ... are they not available or not needed on
4.x trunk?
b) Does this basic implementation distribute acr
2011/9/29 Yury Kats :
> True, but there is a big gap between goals and current state.
> Right now, there is distributed search, but not distributed indexing
> or auto-sharding, or auto-replication. So if you want to use the SolrCloud
> now (as many of us do), you need do a number of things yourself
Agree. Thanks also for clarifying. It helps.
On 09/29/2011 08:50 AM, Yury Kats wrote:
On 9/29/2011 7:22 AM, Darren Govoni wrote:
That was kinda my point. The "new" cloud implementation
is not about replication, nor should it be. But rather about
horizontal scalability where "nodes" manage diffe
On 9/29/2011 7:22 AM, Darren Govoni wrote:
> That was kinda my point. The "new" cloud implementation
> is not about replication, nor should it be. But rather about
> horizontal scalability where "nodes" manage different parts
> of a unified index.
It;s about many things. You stated one, but there
That was kinda my point. The "new" cloud implementation
is not about replication, nor should it be. But rather about
horizontal scalability where "nodes" manage different parts
of a unified index. One of the design goals of the "new" cloud
implementation is for this to happen more or less automati
@Darren: I feel that the question itself is misleading. Creating
shards is meant to separate out the data ... not keep the exact same
copy of it.
I think the two node setup that was attempted by Sam mislead him and
us into thinking that configuring two nodes which are to be named
"shard1" ... some
On 9/27/2011 5:16 PM, Darren Govoni wrote:
> On 09/27/2011 05:05 PM, Yury Kats wrote:
>> You need to either submit the docs to both nodes, or have a replication
>> setup between the two. Otherwise they are not in sync.
> I hope that's not the case. :/ My understanding (or hope maybe) is that
> the
On 09/27/2011 05:05 PM, Yury Kats wrote:
You need to either submit the docs to both nodes, or have a replication
setup between the two. Otherwise they are not in sync.
I hope that's not the case. :/ My understanding (or hope maybe) is that
the new Solr Cloud implementation will support auto-shar
11 matches
Mail list logo
