lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Callum Lamb <cl...@mintel.com>
Subject Re: Stopping a node from receiving any requests temporarily.
Date Wed, 12 Apr 2017 16:01:05 GMT
We can do that in most cases and that's what we've been doing up until now
to prevent failed requests.

All the more incentive to get rid of those joins then I guess!

Thanks.

On Wed, Apr 12, 2017 at 4:16 PM, Erick Erickson <erickerickson@gmail.com>
wrote:

> No good ideas here with current Solr. I just raised SOLR-10484 for the
> generic ability to take a replica out of action (including the
> ADDREPLICA operation).
>
> Your understanding is correct, Solr will route requests to active
> replicas. Is it possible that you can load the "from" core first
> _then_ add the replica that references it? Or do they switch roles?
>
> Best,
> Erick
>
> On Wed, Apr 12, 2017 at 7:39 AM, Callum Lamb <clamb@mintel.com> wrote:
> > Forgot to mention. We're using solr 5.5.2 in Solr cloud mode. Everything
> is
> > single sharded at the moment as the collections are still quite small.
> >
> > On Wed, Apr 12, 2017 at 3:30 PM, Callum Lamb <clamb@mintel.com> wrote:
> >
> >> We have a Solr cluster that still takes queries that join between cores
> (I
> >> know, bad). We can't change that anytime soon however and I was hoping
> >> there was a band-aid I could use in the mean time to make deployments of
> >> new nodes cleaner.
> >>
> >> When we want to add a new node to cluster we'll have a brief moment in
> >> time where one of the cores in that join will be present, but the other
> >> won't.
> >>
> >> My understanding is that even if you stop requests from reaching the new
> >> Solr node with haproxy, Solr can can route requests between nodes on
> it's
> >> own behind haproxy. We've also noticed that this internal Solr routing
> is
> >> not aware of the join in the query and will route a request to a core
> that
> >> joins to another core even if the latter is not present yet (Causing the
> >> query to fail).
> >>
> >> Until we eliminate all the joins, we want to be able to have a node we
> can
> >> do things to, but *gaurentee* it won't receive any requests until we
> decide
> >> it's ready to take requests. Is there an easy way to do this? We could
> try
> >> stopping the Solr's from talking to each other at the network level but
> >> this seems iffy to me and might cause something weird to happen.
> >>
> >> Any ideas?
> >>
> >>
> >>
> >
> > --
> >
> > Mintel Group Ltd | 11 Pilgrim Street | London | EC4V 6RN
> > Registered in England: Number 1475918. | VAT Number: GB 232 9342 72
> >
> > Contact details for our other offices can be found at
> > http://www.mintel.com/office-locations.
> >
> > This email and any attachments may include content that is confidential,
> > privileged
> > or otherwise protected under applicable law. Unauthorised disclosure,
> > copying, distribution
> > or use of the contents is prohibited and may be unlawful. If you have
> > received this email in error,
> > including without appropriate authorisation, then please reply to the
> > sender about the error
> > and delete this email and any attachments.
> >
>

-- 

Mintel Group Ltd | 11 Pilgrim Street | London | EC4V 6RN
Registered in England: Number 1475918. | VAT Number: GB 232 9342 72

Contact details for our other offices can be found at 
http://www.mintel.com/office-locations.

This email and any attachments may include content that is confidential, 
privileged 
or otherwise protected under applicable law. Unauthorised disclosure, 
copying, distribution 
or use of the contents is prohibited and may be unlawful. If you have 
received this email in error,
including without appropriate authorisation, then please reply to the 
sender about the error 
and delete this email and any attachments.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message