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 -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Alex Benjamen <[EMAIL PROTECTED]> > To: solr-user@lucene.apache.org > Sent: Thursday, February 28, 2008 10:12:32 PM > Subject: Master/Slave setup > > I'm trying to figure out how best to handle the replication for our system. > (We're > not using the rsync mechanism because we don't want to have frequent updates > on slaves) > > Current process: > > 1. Master builds new incremental index once an hour. Commit/Optimize, copy > over > index to an nfs exported directory > 2. Slave compares index version on in mounted dir to it's own(once in 2hrs), > if > it finds a newer > index, it will: stop solr, copy over new index, restart solr > > Things are working fine, but, the problem is there is no autowarming. If we > use > the master/slave > setup, then rsync will constantly update the index and the caching will not > work > as well. There > is no reason for us to keep updating the slaves. > > Question: is it possible to simply copy over the new index without restarting > solr? And solr server > will detect that the index has in fact changed, and autowarm based on prev. > queries... > > Should snappuller be used? How does snappuller know not to fetch while the > master is indexing > the feeds... or doing optimize, etc > > Thanks in advance for sugesstions > -Alex >
