Hi,
- Original Message
> From: Jake Luciani
> To: solr-user@lucene.apache.org
> Sent: Wed, March 9, 2011 8:07:00 PM
> Subject: Re: True master-master fail-over without data gaps (choosing CA in
>CAP)
>
> Yeah sure. Let me update this on the Solandra wiki.
t; Lucene ecosystem search :: http://search-lucene.com/
>
>
>
> - Original Message
> > From: Jake Luciani
> > To: "solr-user@lucene.apache.org"
> > Sent: Wed, March 9, 2011 6:04:13 PM
> > Subject: Re: True master-master fail-over without data gaps (c
matext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/
- Original Message
> From: Jake Luciani
> To: "solr-user@lucene.apache.org"
> Sent: Wed, March 9, 2011 6:04:13 PM
> Subject: Re: True master-master fail-over without
gt;>> complete up to the last replication at least and the other slaves would
>>>>> be directed by LB to poll master02 also...
>>>>
>>>> Yeah, "complete up to the last replication" is the problem. It's a data
>>>> gap
>>
h, "complete up to the last replication" is the problem. It's a data
>>> gap
>>> that now needs to be filled somehow.
>>>
>>> Otis
>>>
>>> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
>>> Lucene ecosystem se
; Yeah, "complete up to the last replication" is the problem. It's a data
>> gap
>> that now needs to be filled somehow.
>>
>> Otis
>>
>> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
>> Lucene ecosystem search :: http://search-lucene.com/
&
al Message-----
> > From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
> > Sent: Wednesday, March 09, 2011 9:47 AM
> > To: solr-user@lucene.apache.org
> > Subject: Re: True master-master fail-over without data gaps (choosing CA
> > in CAP)
> >
> >
tic [mailto:otis_gospodne...@yahoo.com]
> Sent: Wednesday, March 09, 2011 9:47 AM
> To: solr-user@lucene.apache.org
> Subject: Re: True master-master fail-over without data gaps (choosing CA
> in CAP)
>
> Hi,
>
>
> - Original Message
> > From: Walter
solr-user@lucene.apache.org
Subject: Re: True master-master fail-over without data gaps (choosing CA
in CAP)
Hi,
- Original Message
> From: Walter Underwood
> On Mar 9, 2011, at 9:02 AM, Otis Gospodnetic wrote:
>
> > You mean it's not possible to have 2 master
Hi,
- Original Message
> From: Walter Underwood
> On Mar 9, 2011, at 9:02 AM, Otis Gospodnetic wrote:
>
> > You mean it's not possible to have 2 masters that are in nearly real-time
>sync?
> > How about with DRBD? I know people use DRBD to keep 2 Hadoop NNs (their
>edit
>
> > l
On 3/9/2011 12:05 PM, Otis Gospodnetic wrote:
But check this! In some cases one is not allowed to save content to
disk (think
copyrights). I'm not making this up - we actually have a customer with this
"cannot save to disk" (but can index) requirement.
Do they realize that a Solr index is on
, 2011 12:16:31 PM
> Subject: RE: True master-master fail-over without data gaps
>
> I guess you could put a LB between slaves and masters, never thought of
> that! :)
>
> -Original Message-
> From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
> Sent:
tp://search-lucene.com/
> -Original Message-
> From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
> Sent: Wednesday, March 09, 2011 8:52 AM
> To: solr-user@lucene.apache.org
> Subject: Re: True master-master fail-over without data gaps
>
> Hi,
>
>
> --
This is why there's block cipher cryptography.
On Wed, Mar 9, 2011 at 9:11 AM, Otis Gospodnetic
wrote:
> On disk, yes, but only indexed, and thus far enough from the original content
> to
> make storing terms in Lucene's inverted index.
>
> Otis
>
> Sematext :: http://sematext.com/ :: Solr
RAMdisk
> ...but the index resides on disk doesn't it??? lol
>
> -Original Message-
> From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
> Sent: Wednesday, March 09, 2011 9:06 AM
> To: solr-user@lucene.apache.org
> Subject: Re: True master-master f
: Robert Petersen
> To: solr-user@lucene.apache.org
> Sent: Wed, March 9, 2011 12:07:27 PM
> Subject: RE: True master-master fail-over without data gaps
>
> ...but the index resides on disk doesn't it??? lol
>
> -Original Message-
> From: Otis Gospodnet
tp://search-lucene.com/
> -Original Message-
> From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
> Sent: Wednesday, March 09, 2011 8:52 AM
> To: solr-user@lucene.apache.org
> Subject: Re: True master-master fail-over without data gaps
>
> Hi,
>
>
> --
...but the index resides on disk doesn't it??? lol
-Original Message-
From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
Sent: Wednesday, March 09, 2011 9:06 AM
To: solr-user@lucene.apache.org
Subject: Re: True master-master fail-over without data gaps
Hi,
- Ori
On Mar 9, 2011, at 9:02 AM, Otis Gospodnetic wrote:
> You mean it's not possible to have 2 masters that are in nearly real-time
> sync?
> How about with DRBD? I know people use DRBD to keep 2 Hadoop NNs (their edit
> logs) in sync to avoid the current NN SPOF, for example, so I'm thinking this
Hi,
- Original Message
>
> I'd honestly think about buffer the incoming documents in some store that's
>actually made for fail-over persistence reliability, maybe CouchDB or
>something.
>And then that's taking care of not losing anything, and the problem becomes
>how
>we make su
operation, repointing the slaves to master02 and
restarting or reloading them etc...
-Original Message-
From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
Sent: Wednesday, March 09, 2011 8:52 AM
To: solr-user@lucene.apache.org
Subject: Re: True master-master fail-over without data gaps
Hi,
- Original Message
>
> > Oh, there is no DB involved. Think of a document stream continuously
> > coming
>in,
> > a component listening to that stream, grabbing docs, and pushing it to
> > master(s).
>
> I don't think Solr is designed for this use case, eg, I wouldn't
> expec
Hi,
- Original Message
>
> Yes, I think this should be pushed upstream - insert a "tee" in the
> document stream so that all documents go to both masters.
> Then use a load balancer to make requests of the masters.
Hm, but this makes the tee app aware of this. What if I want to hi
> Oh, there is no DB involved. Think of a document stream continuously coming
> in,
> a component listening to that stream, grabbing docs, and pushing it to
> master(s).
I don't think Solr is designed for this use case, eg, I wouldn't
expect deterministic results with the current architecture as
Hi,
- Original Message
> From: Robert Petersen
> To: solr-user@lucene.apache.org
> Sent: Wed, March 9, 2011 11:40:56 AM
> Subject: RE: True master-master fail-over without data gaps
>
> If you have a wrapper, like an indexer app which prepares solr docs and
>
Hi,
- Original Message
> If you're using the delta import handler the problem would seem to go
> away because you can have two separate masters running at all times,
> and if one fails, you can then point the slaves to the secondary
> master, that is guaranteed to be in sync because i
h 09, 2011 4:14 AM
To: solr-user@lucene.apache.org
Cc: Jonathan Rochkind
Subject: Re: True master-master fail-over without data gaps
Yes, I think this should be pushed upstream - insert a "tee" in the
document stream so that all documents go to both masters.
Then use a load balancer to
If you're using the delta import handler the problem would seem to go
away because you can have two separate masters running at all times,
and if one fails, you can then point the slaves to the secondary
master, that is guaranteed to be in sync because it's been importing
from the same database?
O
Yes, I think this should be pushed upstream - insert a "tee" in the
document stream so that all documents go to both masters.
Then use a load balancer to make requests of the masters.
The "tee" itself then becomes a possible single point of failure, but
you didn't say anything about the archite
I'd honestly think about buffer the incoming documents in some store that's
actually made for fail-over persistence reliability, maybe CouchDB or
something. And then that's taking care of not losing anything, and the problem
becomes how we make sure that our solr master indexes are kept in sync
30 matches
Mail list logo
