Hi,
- Original Message
From: Jake Luciani jak...@gmail.com
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. I'll send across
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
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?
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 make requests
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 it's
Hi,
- Original Message
From: Robert Petersen rober...@buy.com
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
sends them
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
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 hide
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
expect
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
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
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
...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,
- Original
-
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
From: Robert Petersen rober...@buy.com
To: solr-user
Petersen rober...@buy.com
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 Gospodnetic [mailto:otis_gospodne
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 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
otis_gospodne...@yahoo.com 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 ::
: 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
From: Robert Petersen rober...@buy.com
To: solr-user
9, 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: Wednesday, March 09, 2011 9:10
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
Hi,
- Original Message
From: Walter Underwood wun...@wunderwood.org
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
@lucene.apache.org
Subject: Re: True master-master fail-over without data gaps (choosing CA
in CAP)
Hi,
- Original Message
From: Walter Underwood wun...@wunderwood.org
On Mar 9, 2011, at 9:02 AM, Otis Gospodnetic wrote:
You mean it's not possible to have 2 masters
, 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 Underwood wun...@wunderwood.org
On Mar 9, 2011, at 9:02 AM, Otis Gospodnetic wrote:
You mean it's
-master fail-over without data gaps (choosing CA
in CAP)
Hi,
- Original Message
From: Walter Underwood wun...@wunderwood.org
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
[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 Underwood wun...@wunderwood.org
On Mar 9, 2011, at 9
- Nutch
Lucene ecosystem search :: http://search-lucene.com/
-Original 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
- Nutch
Lucene ecosystem search :: http://search-lucene.com/
-Original 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
]
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 Underwood wun...@wunderwood.org
On Mar 9, 2011, at 9:02 AM, Otis
-lucene.com/
- Original Message
From: Jake Luciani jak...@gmail.com
To: solr-user@lucene.apache.org solr-user@lucene.apache.org
Sent: Wed, March 9, 2011 6:04:13 PM
Subject: Re: True master-master fail-over without data gaps (choosing CA
in
CAP)
Jason,
It's predecessor did
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