Whoa! Replicating takes 15 mins? That's a really long time. Are you including
about the polling interval here? Or is this just raw replication time?

Because this is really suspicious. Are you optimizing your index all the time
or something? Replication should pull down ONLY the changed segments.
But optimizing changes *all* the segments (really, collapses them into one)
and you'd be copying the full index each replication.

Or are you committing after every few documents? Or?

You need to understand why replication takes soooo long before going
any further IMO. It may be perfectly legitimate, but on the surface it sure
doesn't seem right.

Best
Erick

On Wed, Dec 14, 2011 at 10:52 AM, Otis Gospodnetic
<otis_gospodne...@yahoo.com> wrote:
> Hi,
>
> The slave will get the changes next time it polls the master and master tells 
> it the index has changed.
> Note that master doesn't replicate to slave, but rather the slave copies 
> changes from the master.
>
> Otis
> ----
> Performance Monitoring SaaS for Solr - 
> http://sematext.com/spm/solr-performance-monitoring/index.html
>
>
>
>>________________________________
>> From: Tarun Jain <tjai...@yahoo.com>
>>To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
>>Sent: Wednesday, December 14, 2011 10:43 AM
>>Subject: Re: CRUD on solr Index while replicating between master/slave
>>
>>Hi,
>>We have an index which needs constant updates in the master.
>>
>>One more question..
>>The scenario is
>>1) Master starts replicating to slave (takes approx 15 mins)
>>
>>2) We do some changes to index on master while it is replicating
>>
>>So question is what happens to the changes in master index while it is 
>>replicating.
>>Will the slave get it or not?
>>
>>
>>Tarun Jain
>>-=-
>>
>>
>>
>>
>>----- Original Message -----
>>From: Erick Erickson <erickerick...@gmail.com>
>>To: solr-user@lucene.apache.org; Tarun Jain <tjai...@yahoo.com>
>>Cc:
>>Sent: Tuesday, December 13, 2011 4:18 PM
>>Subject: Re: CRUD on solr Index while replicating between master/slave
>>
>>No, you can search on the master when replicating, no
>>problem.
>>
>>But why do you want to? The whole point of master/slave
>>setups is to separate indexing from searching machines.
>>
>>Best
>>Erick
>>
>>On Tue, Dec 13, 2011 at 4:10 PM, Tarun Jain <tjai...@yahoo.com> wrote:
>>> Hi,
>>> Thanks.
>>> So just to clarify here again while replicating we cannot search on master 
>>> index ?
>>>
>>> Tarun Jain
>>> -=-
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Otis Gospodnetic <otis_gospodne...@yahoo.com>
>>> To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
>>> Cc:
>>> Sent: Tuesday, December 13, 2011 3:03 PM
>>> Subject: Re: CRUD on solr Index while replicating between master/slave
>>>
>>> Hi,
>>>
>>> Master: Update/insert/delete docs    -->    Yes
>>> Slaves: Search                              -->   Yes
>>>
>>> Otis
>>> ----
>>>
>>> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
>>> Lucene ecosystem search :: http://search-lucene.com/
>>>
>>>
>>>>________________________________
>>>> From: Tarun Jain <tjai...@yahoo.com>
>>>>To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
>>>>Sent: Tuesday, December 13, 2011 11:15 AM
>>>>Subject: CRUD on solr Index while replicating between master/slave
>>>>
>>>>Hi,
>>>>When replication is happening between master to slave what operations can 
>>>>we do on the master & what operations are possible on the slave?
>>>>I know it is not adivisable to do DML on the slave index but I wanted to 
>>>>know this anyway. Also I understand that doing DML on a slave will make the 
>>>>slave index incompatible with the master.
>>>>
>>>>Master
>>>>================
>>>>Search                              -->   Yes/No
>>>>Update/insert/delete docs    -->    Yes/No
>>>>
>>>>Slave
>>>>=================
>>>>Search                              -->    Yes/No
>>>>Update/insert/delete docs    -->    Yes/No
>>>>
>>>>Please share any other caveats that you have discovered regarding the above 
>>>>scenario that might be helpful.
>>>>
>>>>Thanks
>>>>-=-
>>>>
>>>>
>>>>
>>
>>
>>
>>

Reply via email to