But note one thing here.  Pulling a merely modified index (its snapshot) and 
not the fully optimized index means you'll only pull the delta, while if you 
fully optimize the index and then the snapshooter runs and then snappuller 
runs, the *whole* index will be pulled over the network from master to slave.  
This is good in some situations, and bad in others.  In your case, it's 
probably a good thing - you are likely okay with the large network transfer and 
would not be okay with an unoptimized index being hit at high query rate.

Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

----- Original Message ----
> From: Walter Underwood <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Friday, February 29, 2008 2:36:12 PM
> Subject: Re: Master/Slave setup
> 
> In solrconfig.xml, configure a listener for "postOptimize" but not for
> "postCommit". That listener runs snapshooter. You will only create
> snapshots after an optimize. That's what I do.
> 
> wunder
> 
> On 2/29/08 11:38 AM, "Alex Benjamen"  wrote:
> 
> > OK, I'll give it a shot... Couple of issues I see with the snappuller:
> >  
> > 1. When the master performs a commit, and then optimize, there is nothing to
> > prevent
> >    snappuller to pul a non-optimized index?
> >  
> > 2 Do uncommitted updates constitute a different index version... suppose I
> > post 10 XML 
> >   files on update, and do not commit.   The snappuller happens to run at 
> > that
> > time - will 
> >   it pull the uncommitted index, or is it smart enough to detect that the
> > newer index is 
> >   not committed/optimized
> > 
> > I suppose, I could write to some file after optimize is done (index version)
> > on the master,
> > and modify snappuller to look at that file... but it would be good if that
> > happens "out of the box"
> >  
> > Thanks,
> > Alex
> >  
> >  
> > 
> > ________________________________
> > 
> > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED]
> > Sent: Thu 2/28/2008 8:16 PM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Master/Slave setup
> > 
> > 
> > 
> > Alex,
> > 
> > I think you should rethink the approach you described and reconsider using 
> > the
> > provided replication scripts.
> > 
> > - How often the searchers see the new index depends on how often the
> > snappuller + snapinstaller are run on slaves.
> > - If you want the searchers to get a new and optimized index every 2 hours,
> > there is no need to optimize the index on slaves every 1 hour.
> > - If you use snappuller + snapinstaller you will not need to restart Solr
> > (good!) and autowarming will be done (good again!)
> > 
> > Otis
> > --
> > 
> > 
> 
> 


Reply via email to