[ 
https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618735#action_12618735
 ] 

Otis Gospodnetic commented on SOLR-561:
---------------------------------------

Comment about the solrconfig entry for replication on the *master*:

{code:xml}

<requestHandler name="/replication" class="solr.ReplicationHandler" >
    <lst name="master">
        <!--Replicate on 'optimize' it can also be  'commit' -->
        <str name="replicateAfter">commit</str>
         <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>       
   
    </lst>
</requestHandler>

{code} 

Reading the above makes one think that it is the master that *does* the actual 
replication.  In fact, the master only creates a snapshot of the index and 
other files after either commit or optimize.  It is the slaves that copy the 
snapshots.  So while we refer to the whole process as replication, I think the 
configuration elements' names should reflect the actual actions to ease 
understanding and avoid confusion.

Concretely, I think "replicateAfter" should be called "snapshootAfter" or some 
such.

+1 for Hoss' suggestion to decouple scheduling from the handler that can 
replicate/copy on-demand
+1 for Shalin's suggestion to expose an HTTP interface to enable/disable 
snapshooting on masters and copying/replication on slaves.


> Solr replication by Solr (for windows also)
> -------------------------------------------
>
>                 Key: SOLR-561
>                 URL: https://issues.apache.org/jira/browse/SOLR-561
>             Project: Solr
>          Issue Type: New Feature
>          Components: replication
>    Affects Versions: 1.3
>         Environment: All
>            Reporter: Noble Paul
>            Assignee: Shalin Shekhar Mangar
>         Attachments: deletion_policy.patch, SOLR-561-core.patch, 
> SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch
>
>
> The current replication strategy in solr involves shell scripts . The 
> following are the drawbacks with the approach
> *  It does not work with windows
> * Replication works as a separate piece not integrated with solr.
> * Cannot control replication from solr admin/JMX
> * Each operation requires manual telnet to the host
> Doing the replication in java has the following advantages
> * Platform independence
> * Manual steps can be completely eliminated. Everything can be driven from 
> solrconfig.xml .
> ** Adding the url of the master in the slaves should be good enough to enable 
> replication. Other things like frequency of
> snapshoot/snappull can also be configured . All other information can be 
> automatically obtained.
> * Start/stop can be triggered from solr/admin or JMX
> * Can get the status/progress while replication is going on. It can also 
> abort an ongoing replication
> * No need to have a login into the machine 
> This issue can track the implementation of solr replication in java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to