On Thu, Jul 17, 2008 at 4:43 AM, Yonik Seeley (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614146#action_12614146 > ] > > Yonik Seeley commented on SOLR-561: > ----------------------------------- > > I love how easy this is to set up! Thanks. > > A couple of issues I noticed while testing: > - it doesn't seem like old files are being removed on the slave for me... > actually I think this is related to the fact that I don't see old searchers > being cleaned up... my slave currently has 4 open - one for each index > version. I guess Lucene must be cleaning it up because that is what the deletion policy says > - segment_* should be copied last... then if we crash in the middle, > everything will work fine... lucene will open the previous index version > automatically. Good point. Will incorporate that > - since a single index file is likely to be part of multiple indicies, > commands from the slave to the master to replicate this file should reference > the index version being replicated. This allows time-based reservation of a > specific index commit point. Because the file names are unique it did not matter if I used the index version (or does it) . Please clarify > > What happens when the slave is replicating an index, and some of the files > become missing on the master? Seems like the slave should simply abandon the > current replication effort. Next time the master is polled, the new index > version will be discovered and the process can start again as normal. Yeah . It does that . If all the files are not copied completely it aborts. > > What happens if replication takes a really long time? I assume that no new > replications will be kicked off until the current one has finished? You are right. When the replication process starts , a lock is acquired. The lock is released only after the process completes > > >> 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 >> Attachments: deletion_policy.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. > >
-- --Noble Paul
