On 2/26/2019 2:39 AM, Andreas Mock wrote:
currently we are looking at Apache Solr as a solution
for searching. One important component is high availability.
I digged around finding out that HA is built in via
SolrCloud which means I have to install ZooKeeper in
a production environment which need
something?
>
> Best regards
> Andreas
>
>> -Ursprüngliche Nachricht-
>> Von: Walter Underwood
>> Gesendet: Dienstag, 26. Februar 2019 16:14
>> An: solr-user@lucene.apache.org
>> Betreff: Re: High Availability with two nodes
>>
>> Solr C
Solr Cloud automatically choose a leader and a follower.
I am not a fan of cold standby hosts, because you don’t really know whether
they work. You have two hosts, so keep them both hot, put a load balancer in
front of them, and send all the traffic to both of them all the time. If one
fails, y
I would go for SolrCloud, but for simple active / passive scenarios you can use
a simple http load balancer with health checks.
> Am 26.02.2019 um 10:39 schrieb Andreas Mock :
>
> Hi all,
>
> currently we are looking at Apache Solr as a solution
> for searching. One important component is high
I have hard of somone doing this with their whole FARM and application. They
used Amazon AWS and had some sort of fail over set up.
I will be curious to herar what others say/have done.
Dennis Gearon
Signature Warning
EARTH has a Right To Life,
otherwise we all die.
Read 'Ho
gt;> To: solr-user@lucene.apache.org; r...@intelcompute.com
>> Sent: Thu, January 7, 2010 10:45:20 AM
>> Subject: Re: High Availability
>>
>> I've tried having two servers set up to replicate each other, and it is not a
>> pretty thing. It seems that SOLR doesn't
ache.org; r...@intelcompute.com
> Sent: Thu, January 7, 2010 10:45:20 AM
> Subject: Re: High Availability
>
> I've tried having two servers set up to replicate each other, and it is not a
> pretty thing. It seems that SOLR doesn't really do any checking of the
> version
> # to s
...@yahoo.com
"Once you start down the dark path, forever will it
dominate your destiny. Consume you it will " - Yoda
- Original Message
From: "r...@intelcompute.com"
To: solr-user@lucene.apache.org
Sent: Mon, January 4, 2010 11:37:22 AM
Subject: Re: High Availab
te, correct?
>
> "Once you start down the dark path, forever will it
> dominate your destiny. Consume you it will " - Yoda
> - Original Message
> From: ""
> To:
> Sent: Mon, January 4, 2010 11:17:40 AM
> Subject: Re: High Availability
>
your destiny. Consume you it will " - Yoda
> - Original Message
> From: ""
> To:
> Sent: Mon, January 4, 2010 11:17:40 AM
> Subject: Re: High Availability
> Have you looked into a basic floating IP setup?
> Have the master also replicate to another hot-spar
ompute.com"
To: solr-user@lucene.apache.org
Sent: Mon, January 4, 2010 11:17:40 AM
Subject: Re: High Availability
Have you looked into a basic floating IP setup?
Have the master also replicate to another hot-spare master.
Any downtime during an outage of the 'live' master would be m
Have you looked into a basic floating IP setup?
Have the master also replicate to another hot-spare master.
Any downtime during an outage of the 'live' master would be minimal as the
hot-spare takes up the floating IP.
On Mon 04/01/10 16:13 , Matthew Inger wrote:
> I'm kind of stuck and l
Hi Hoss,
Yes I know that, but I want to have a proper dummy backup (something that
could be kept in a very controlled environment). I thought about using this
approach (a slave just for this purpose), but if I'm using it just as a
backup node there is no reason I don't use a proper backup structur
: I'm setting up a backup task to keep a copy of my master index, just to
: avoid having to re-build my index from scratch. And other important issue is
every slave is a backup of the master, so you don't usually need a
seperate backup mechanism.
re-building hte index is more about peace of mind
OK, I'll define it as a procedure in my disaster recovery plan.
That would be great. I'm looking forward to it.
Thanks,
Daniel
On 8/10/07 18:07, "Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> On 10/8/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote:
>> Hmm, is there any exception thrown in case the i
On 10/8/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote:
> Hmm, is there any exception thrown in case the index get corrupted (if it's
> not caused by OOM and the JVM crashes)? The document uniqueness SOLR offers
> is one of the many reasons I'm using it and should be excellent to know when
> it's go
Hi Yonik.
It looks pretty good.
I hope I'm not the one who will post a very odd crash after a while. :)
OK, so is very unlikely that a OOM it's going to happen, as I've set my JVM
heap size to 1.5G.
Hmm, is there any exception thrown in case the index get corrupted (if it's
not caused by OOM and
On 10/8/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote:
> Well I believe I can live with some staleness at certain moments, but it's
> not good as users are supposed to need it 24x7. So the common practice is to
> make one of the slaves as the new master and switch things over to it and
> after the
Hi YoniK.
I'll check if I comment about it at this level and if it's OK I'll bring
other details. Sorry if I can't do it right now, but I don't want to brake
my company's policies.
Well I believe I can live with some staleness at certain moments, but it's
not good as users are supposed to need it
We run multiple, identical, independent copies. No master/slave
dependencies. Yes, we run indexing N times for N servers, but
that's what CPU is for and I sleep better at night. It makes
testing and deployment trivial, too.
wunder
==
Walter Underwood
Search Guy, Netflix
On 10/8/07 4:05 AM, "Dani
On 10/8/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote:
> I'm about to deploy SOLR in a production environment
Cool, can you share exactly what it will be used for?
> and so far I'm a bit
> concerned about availability.
>
> I have a system that is responsible for fetching data from a database and
21 matches
Mail list logo
