Hmmm.... I'd never thought of this configuration. It actually does make sense if Solr is not the "System Of Record" (master copy).
Please file a JIRA request for bidirectional (or rather peer-to-peer) replication. On Thu, Jan 7, 2010 at 12:49 PM, Otis Gospodnetic <otis_gospodne...@yahoo.com> wrote: > Your setup with the master behind a LB VIP looks right. > I don't think replication in Solr was meant to be bidirectional. > > Otis > -- > Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch > > > > ----- Original Message ---- >> From: Matthew Inger <mattin...@yahoo.com> >> To: solr-user@lucene.apache.org; r...@intelcompute.com >> Sent: Thu, January 7, 2010 10:45:20 AM >> Subject: Re: High Availability >> >> I've tried having two servers set up to replicate each other, and it is not a >> pretty thing. It seems that SOLR doesn't really do any checking of the >> version >> # to see if the version # on the master is > the version # on the slave >> before >> deciding to replicate. It only looks to see if it's different. As a result, >> what ends up happening is this: >> >> 1. Both servers at same revision, say revision 100 >> 2. Update Master 1 to revision 101 >> 3. Master 2 starts pull of revision 101 >> 4. Master 1 sees master 2 has different revision and starts pull of revision >> 100 >> >> See where it's going? Eventually, both servers seem to end up back at >> revision >> 100, and my updates get lost, so my sequencing might be a little out of wack >> here, but nonetheless having two servers setup as slaves to each other does >> not >> work properly. I would think though that with a small code change to check >> to >> see if the revision # has increased before pulling the file, that would solve >> the issue. >> >> In the mean time, my plan is to: >> 1. Setup two index update servers as masters behind an F5 load balancer >> with a >> VIP in an active/passive configuration. >> 2. Setup N search servers as slaves behind an F5 load balancer with a VIP >> in an >> round robin configuration. Replication would be from the master's VIP, >> instead >> of any one particular master. >> 3. Index update servers would have a handler would would do delta updates >> every >> so often to keep both servers in sync with the database (i'm only indexing a >> complex database here, which doesn't lend itself well to sql querying on the >> fly). >> >> Ideally, i'd love to be able to force the master servers to update if either >> one >> of them switches from passive to active state, but am not sure how to >> accomplish >> that. >> >> >> ---- >> 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" >> To: solr-user@lucene.apache.org >> Sent: Mon, January 4, 2010 11:37:22 AM >> Subject: Re: High Availability >> >> >> Even when Master 1 is alive again, it shouldn't get the floating IP until >> Master >> 2 actually fails. >> >> So you'd ideally want them replicating to eachother, but since one will only >> be >> updated/Live at a time, it shouldn't cause an issue with cobbling data (?). >> >> Just a suggestion tho, not done it myself on Solr, only with DB servers. >> >> >> >> >> On Mon 04/01/10 16:28 , Matthew Inger wrote: >> >> > So, when the masters switch back, does that mean, we have to force a >> > full delta update, correct? >> > ---- >> > "Once you start down the dark path, forever will it >> > dominate your destiny. Consume you it will " - Yoda >> > ----- Original Message ---- >> > From: "" >> > To: >> > 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 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/ >> > >> > >> Message sent via Atmail Open - http://atmail.org/ > > -- Lance Norskog goks...@gmail.com
