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" <[EMAIL PROTECTED]> 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 > -- > >
