In the case of using a shared (SAN) index between 2 masters, what happens if 
the live master fails in such a way that the index remains "locked" (such as if 
some hardware failure and it did not unlock/close index).  Will the other 
master be able to open/write to the index as new documents are added?

Also, if that can work ok, would it work if you have a LB (VIP) from both 
indexing and replication sides of the 2 masters, such that some VIP used by 
solrj for indexing new documents via HTTP, and the same VIP used by slave 
searchers for replication?  That sounds like it would work.




On Oct 11, 2011, at 3:16 PM, Otis Gospodnetic wrote:

> Hello,
> 
> Yes, you've read about NFS, which is why I gave the example of a SAN (which 
> can have multiple power supplies, controllers, etc.)
> 
> Yes, should be OK to have multiple Solr instances have the same index open, 
> since only one of them will actually be writing to it, thanks to LB.
> 
> Otis
> ----
> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
> Lucene ecosystem search :: http://search-lucene.com/
> 
> 
>> ________________________________
>> From: Brandon Ramirez <brandon_rami...@elementk.com>
>> To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
>> Sent: Tuesday, October 11, 2011 2:55 PM
>> Subject: RE: Replication with an HA master
>> 
>> Using a shared volume crossed my mind too, but I discarded the idea because 
>> of literature I have read about Lucene performing poorly against remote file 
>> systems.  But then I suppose a SAN wouldn't be a remote file system in the 
>> same sense as an NFS-mounted NAS or similar.
>> 
>> Should I be concerned about two solr instances on two machines having the 
>> same SAN-based index open, as long as only one of them is receiving 
>> requests?  I would think in theory it would work, but I don't have any 
>> production-level experience with Solr yet, only textbook knowledge.
>> 
>> 
>> Brandon Ramirez | Office: 585.214.5413 | Fax: 585.295.4848 
>> Software Engineer II | Element K | www.elementk.com
>> 
>> 
>> -----Original Message-----
>> From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com] 
>> Sent: Tuesday, October 11, 2011 2:28 PM
>> To: solr-user@lucene.apache.org
>> Subject: Re: Replication with an HA master
>> 
>> A few alternatives:
>> * Have the master keep the index on a shared disk (e.g. SAN)
>> * Use LB to easily switch to between masters, potentially even automatically 
>> if LB can detect the primary is down
>> 
>> Otis
>> ----
>> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Lucene ecosystem 
>> search :: http://search-lucene.com/
>> 
>> 
>>> ________________________________
>>> From: Robert Stewart <bstewart...@gmail.com>
>>> To: solr-user@lucene.apache.org
>>> Sent: Friday, October 7, 2011 10:22 AM
>>> Subject: Re: Replication with an HA master
>>> 
>>> 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/>
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 

Reply via email to