So, when the masters switch back, does that mean, we have to force a full delta update, correct?
---- mattin...@yahoo.com "Once you start down the dark path, forever will it dominate your destiny. Consume you it will " - Yoda ----- Original Message ---- From: "r...@intelcompute.com" <r...@intelcompute.com> To: solr-user@lucene.apache.org Sent: Mon, January 4, 2010 11:17:40 AM Subject: Re: High Availability Have you looked into a basic floating IP setup? Have the master also replicate to another hot-spare master. Any downtime during an outage of the 'live' master would be minimal as the hot-spare takes up the floating IP. On Mon 04/01/10 16:13 , Matthew Inger <mattin...@yahoo.com> wrote: > I'm kind of stuck and looking for suggestions for high availability > options. I've figured out without much trouble how to get the > master-slave replication working. This eliminates any single points > of failure in the application in terms of the application's searching > capability. > I would setup a master which would create the index and several > slaves to act as the search servers, and put them behind a load > balancer to distribute the requests. This would ensure that if a > slave node goes down, requests would continue to get serviced by the > other nodes that are still up. > The problem I have is that my particular application also has the > capability to trigger index updates from the user interface. This > means that the master now becomes a single point of failure for the > user interface. > The basic idea of the app is that there are multiple oracle > instances contributing to a single document. The volume and > organization of the data (database links, normalization, etc...) > prevents any sort of fast querying via SQL to do querying of the > documents. The solution is to build a lucene index (via solr), and > use that for searching. When updates are made in the UI, we will > also send the updates directly to the solr server as well (we don't > want to wait some arbitrary interval for a delta query to run). > So you can see the problem here is that if the master is down, the > sending of the updates to the master solr server will fail, thus > causing an application exception. > I have tried configuring multiple solr servers which are both setup > as masters and slaves to each other, but they keep clobber each > other's index updates and rolling back each other's delta updates. > It seems that the replication doesn't take the generation # into > account and check that the generation it's fetching is > the > generation it already has before it applies it. > I thought of maybe introducing a JMS queue to send my updates to and > having the JMS message listener set to manually acknowledge the > messages only after a succesfull application of the solrj api calls, > but that seems kind of contrived, and is only a band-aid. > Does anyone have any suggestions? > ---- > "Once you start down the dark path, forever will it > dominate your destiny. Consume you it will " - Yoda > > Message sent via Atmail Open - http://atmail.org/
