My scenario was to have a single master and two slaves replicating from it.
In case the Master fails, we had a failover master. But synchornizing both
Masters was a problem. So, we planned to have a common index shared with 2
Masters. Indexing will happen via Master1 and if it fails then it would be
via Master2.
This was not as simple as we thought. there were lot of locking issues. so
i changed the lock type to "none" and it worked. But after some updates,
the index becomes unstable.
Thanks,
Prasi
On Fri, Jun 27, 2014 at 6:10 AM, Erick Erickson <erickerick...@gmail.com>
wrote:
> bq: Avoid all the ridiculous complexity of "cloud"
>
> And then re-introduce a single point of failure. Bad disk ==
> unfortunate consequences....
>
> But frankly I don't see why you would ever _need_ to write from two
> Solr instances. Wouldn't simply having one writer (which you could
> change when you restarted) and multiple readers (which is OOB
> functionality now) work?
>
> And as far as offloading analysis, the preanalyzed field types seem
> interesting (although I haven't played with them)
>
> Erick
>
> On Thu, Jun 26, 2014 at 12:49 PM, Walter Underwood
> <wun...@wunderwood.org> wrote:
> > Cool? More like "generally useless". --wunder
> >
> > On Jun 26, 2014, at 12:44 PM, "Jack Krupansky" <j...@basetechnology.com>
> wrote:
> >
> >> Erick, I agree, but... wouldn't it be SO COOL if it did work! Avoid all
> the ridiculous complexity of "cloud".
> >>
> >> Have a temporary lock to permit and exclude updates.
> >>
> >> -- Jack Krupansky
> >>
> >> -----Original Message----- From: Erick Erickson
> >> Sent: Thursday, June 26, 2014 12:37 PM
> >> To: solr-user@lucene.apache.org
> >> Subject: Re: Two solr instances access common index
> >>
> >> bq: But my scenario is that both solr instances would write to the
> common
> >> directory
> >>
> >> Do NOT do this. Don't even try. I guarantee Bad Things Will Happen.
> >>
> >> Why do you want to do this? To save disk space? Accomplish NRT
> >> searching on multiple machines?
> >>
> >> Please define the problem you're trying to solve and why existing
> supported
> >> ways of using Solr wouldn't work for you, e.g. SolrCloud or master/slave
> >> setups before asking for a specific solution, as this sounds very much
> like an
> >> XY problem.
> >>
> >> Best,
> >> Erick
> >>
> >> On Thu, Jun 26, 2014 at 4:25 AM, Prasi S <prasi1...@gmail.com> wrote:
> >>> Can you please tell me whihc solr version you have tried with? I tried
> >>> giving
> >>>
> >>> <lockType>${solr.lock.type:none}</lockType> in 2 solr instances and
> now it
> >>> is working. I am not getting the write lock exception when starting the
> >>> second instance.
> >>>
> >>> But my scenario is that both solr instances would write to the common
> >>> directory ( but not both simultaneously for sure). Is there any
> drawback of
> >>> using "noLock"
> >>>
> >>> Please advice.
> >>>
> >>> Thanks,
> >>> Prasi
> >>>
> >>>
> >>> On Thu, Jun 26, 2014 at 3:20 PM, Uwe Reh <r...@hebis.uni-frankfurt.de>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> with the lock type 'simple' I have tree instances (different JREs,
> >>>> GC-Problem) running on the same files.
> >>>> You should use this option only for a readonly system. Otherwise it's
> easy
> >>>> to corrupt the index.
> >>>>
> >>>> Maybe you should have a look on replication or SolrCloud.
> >>>>
> >>>> Uwe
> >>>>
> >>>>
> >>>> Am 26.06.2014 11:25, schrieb Prasi S:
> >>>>
> >>>> Hi,
> >>>>> Is it possible to point two solr instances to point to a common index
> >>>>> directory. Will this work wit changing the lock type?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Prasi
> >>>>>
> >>
> >
> > --
> > Walter Underwood
> > wun...@wunderwood.org
> >
> >
> >
>
