Hi, Yes, I thought of flag file + wrapper script tricks, but that didn't sound super elegant either, and the other differences in behaviour between master and slave are also true.
Hmmmm, I've always wanted to try DRDB (http://www.drbd.org/). Master->(Master+Slaves) replication via DRDB? I imagine it would be expensive... So if I want to turn a Slave into a Master, the best thing to do is to swap solrconfigs and restart the ex-Slave to turn it into a Master. The more expensive solution might be to have Solr instances run on top of a SAN and then one could really have multiple Master instances, one in stand-by mode and ready to be started as the new Master if the current Master decides to go on vacation. Any flaws there? Out of curiosity, how does CNet handle Master redundancy? Otis ----- Original Message ---- From: Chris Hostetter <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Wednesday, June 20, 2007 9:40:51 PM Subject: Re: Slave/Master swap : I'm wondering if there are slicker ways to do this, ways that would : minimize the downtime, for instance. Perhaps, just like Will Johnson is : trying to make IndexSchema updateable in a live system, the snapshooter : could be turned on/off programatically, say via a special request : handler. and easy way to do that would be to modify the configuration of RunExecutableListener in the solrconfig.xml to execute a wrapper script around snapshooter that only runs it if a flag file exists on disk. the problem is there are other things you typically want differnet between a master and a slave ... uses of the QuerySenderListener (it could also be modified to check for flag file i suppose)m cache sizes, and cache autowarming. -Hoss
