After Matthew's comment I was thinking about putting them both behind a load balancer, with the LB directing all traffic to one until it fails and then kick over to the other one.
In your architectures I'm guessing the masters share the same physical index, but do the slaves share the same index as the masters or do you use rsync or some other mechanism to distribute copies. Thanks -Rakesh On 7/29/08 5:07 PM, "Alexander Ramos Jardim" <[EMAIL PROTECTED]> wrote: > You could implement a script that woiuld control which master server is > indexing and put them behind something like a NAT. > > I use that that control my master redundancy. > > 2008/7/29 Rakesh Godhani <[EMAIL PROTECTED]> > >> Thanks for the input, much appreciated. >> -Rakesh >> >> >> >> On 7/29/08 12:18 PM, "Matthew Runo" <[EMAIL PROTECTED]> wrote: >> >>> As far as I know only one machine can write to an index at a time. >>> More than that and I got corrupted indexes. >>> >>> Thanks! >>> >>> Matthew Runo >>> Software Developer >>> Zappos.com >>> 702.943.7833 >>> >>> On Jul 28, 2008, at 11:25 AM, Rakesh Godhani wrote: >>> >>>> >>>> Hi, we are currently evaluating Solr and have been browsing the >>>> archives for >>>> one particular issue but can¹t seem to find the answer, so please >>>> forgive me >>>> if I¹m asking a repetitive question. We like the idea of having >>>> multiple >>>> slave servers serving up queries and a master performing updates. >>>> However >>>> the the issue for us there is no redundancy for the master. So a >>>> couple of >>>> questions: >>>> >>>> 1. Can there be multiple masters (or update servers) sharing the >>>> same index >>>> files, performing updates at the same time (ie. Hosting the index on >>>> a SAN)? >>>> >>>> 2. Is there a recommended architecture utilizing a SAN. (For >>>> example 2 >>>> slaves and 2 masters sharing a SAN). We current don¹t have that many >>>> records prob about a million and growing. We are mainly concerned >>>> about >>>> redundancy, then performance. >>>> >>>> Thanks >>>> -Rakesh >>>> >>>> >>>> >>> >>> >> >> >> >
