Yeah - as I just said in another email, I think this is fairly low hanging
fruit - only reason I have not gotten after it (besides infinite time) is that
SolrCloud indexing side will likely move away from replication. This is still a
nice feature to have IMO though.
- Mark
On Feb 24, 2011, at 9:51 AM, Jan Høydahl wrote:
> I think all of this should be adapted for SolrCloud.
> ZK should be the one knowing which is master and slave. ZK should know
> whether replication on a slave is disabled or not. To disable replication it
> should be enough to set a new value in ZK, and the node will be notified and
> change behaviour at next poll. Thus, in a ZK environment we'll not need the
> replicationHandler section of solrconfig.xml at all, as it should be stored
> in distinct ZK nodes, not? We somehow have to refactor this to work
> seamlessly with and without ZK.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> On 24. feb. 2011, at 05.10, Otis Gospodnetic wrote:
>
>> Hi,
>>
>>
>> ----- Original Message ----
>>> From: Ahmet Arslan <iori...@yahoo.com>
>>> Subject: disable replication in a persistent way
>>>
>>> Hello,
>>>
>>> solr/replication?command=disablepoll disables replication on slave(s).
>>> However
>>> it is not persistent. After solr/tomcat restart, slave(s) will continue
>>> polling.
>>>
>>>
>>> Is there a built-in way to disable replication on slave side in a
>>> persistent
>>> manner?
>>
>> Not that I know of.
>>
>> Hoss or somebody else will correct me if I'm wrong :)
>>
>>> Currently I am using system property substitution along with
>>> solrcore.properties file to simulate this.
>>>
>>> <lst name="slave">
>>> <str name="enable">${enable.slave:false}</str>
>>>
>>> #solrcore.properties in slave
>>> enable.master=true
>>>
>>> And modify solrcore.properties with a custom solr request handler after
>>> the
>>> disablepoll command, to make it persistent. It seems that there is no
>>> existing
>>> mechanism to write solrconfig.properties file, am I correct?
>>
>> What about modifying the existing classes (the one/ones that handle the
>> disablepoll command) to take another param: persist=true|false ?
>> Would that be better than a custom Solr request handler that requires a
>> separate
>> call?
>>
>> Otis
>> ----
>> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
>> Lucene ecosystem search :: http://search-lucene.com/
>>
>
- Mark Miller
lucidimagination.com
