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 --
