Your idea sounds like the correct path. Setup 2 masters, one running in "slave" mode which pulls replicas from the live master. When/if live master goes down, you just reconfigure and restart the backup master to be the live master. You'd also need to then start data import on the backup master (enable/start cron job?), and redirect slave searchers to pull replicas from the new live master. All that could be done using scripts or something like puppet possibly.
Another solution maybe is to run 2 "live" masters, which both index the same content from the same data source. If one goes down, then you just need to redirect slave searchers to the backup master for replication. I am also starting a similar project which needs some disaster recovery processes in place, so any other info would be useful to me as well. Bob On Oct 7, 2011, at 9:53 AM, Brandon Ramirez wrote: > We are getting ready to start a project using Solr as our backend search > engine and I am trying to devise a deployment architecture that works for us. > We definitely need a master/slave replication strategy, that's for sure, but > my concern is the master becomes a single point of failure. > > Fortunately, real-time search is not a requirement for us. If search results > are a few minutes out of sync with our database, it's not a big deal. > > So what I would like to do is have a set of query servers (slaves) that are > only used for querying, no indexing and have them use Solr's HTTP replication > mechanism on a 2 or 3 minute interval. To get HA indexing, I'd like to have > 2 masters: a primary and a standby. All indexing requests go to the primary > unless it's taken out of service. To keep the standby ready to takeover if > it needs to, it needs to be more up to date than the slaves. I'd like to > have it replicate every 30 seconds or so. > > The reason I'm asking about it on this list is that I haven't seen any Solr > documentation or even anything that talks about this. I can't be the only > one concerned about having a single point of failure, so I'm reaching out to > see what others have done in this case before I go with my own solution. > > > Brandon Ramirez | Office: 585.214.5413 | Fax: 585.295.4848 > Software Engineer II | Element K | www.elementk.com<http://www.elementk.com/> >
