I also confuse to this long time.
--
View this message in context:
http://lucene.472066.n3.nabble.com/SOLR-Cloud-Rebuild-core-tp4141869p4142194.html
Sent from the Solr - User mailing list archive at Nabble.com.
Plus one to Shawn's method below. I'm using that method in production right now
and on occasion there's only a small blip of queued queries while the alias is
in the process of swapping.
Thanks,
Greg
On Jun 15, 2014, at 10:36 AM, Shawn Heisey wrote:
> On 6/14/2014 1:29 PM, Branham, Jeremy [HR
On 6/14/2014 1:29 PM, Branham, Jeremy [HR] wrote:
> We are looking to move from legacy master/slave configuration to the cloud
> configuration.
>
> In the past we have handled rebuilding cores by using a 'live' core and a
> core for performing the rebuild on.
> When a rebuild is complete, we swa
@lucene.apache.org
Subject: Re: SOLR Cloud Rebuild core
Exactly. Do one commit at the end. I do this for indexes with 4 million or more
documents. Works fine.
I don't know of a way to flush the queued add-document commands. Solr does not
have the concept of a single transaction that can be dr
wood [mailto:wun...@wunderwood.org]
> Sent: Saturday, June 14, 2014 2:44 PM
> To: solr-user@lucene.apache.org
> Subject: Re: SOLR Cloud Rebuild core
>
> If you don't need near real-time index freshness, why are you implementing
> Solr Cloud? It is harder to set up and adds fun
work - if the reindexing fails could we bail on the commit
and still have a sane core?
Jeremy Branham
-Original Message-
From: Walter Underwood [mailto:wun...@wunderwood.org]
Sent: Saturday, June 14, 2014 2:44 PM
To: solr-user@lucene.apache.org
Subject: Re: SOLR Cloud Rebuild core
If you
If you don't need near real-time index freshness, why are you implementing Solr
Cloud? It is harder to set up and adds functionality you are not using. Solr
Cloud is designed for a fully live index, not offline indexing.
Also, I don't understand why people do this complicated offline build and
