You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Callum Lamb <cl...@mintel.com> on 2017/04/12 14:30:34 UTC
Stopping a node from receiving any requests temporarily.
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.
Re: Stopping a node from receiving any requests temporarily.
Posted by Callum Lamb <cl...@mintel.com>.
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 <er...@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 <cl...@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 <cl...@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.
Re: Stopping a node from receiving any requests temporarily.
Posted by Erick Erickson <er...@gmail.com>.
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 <cl...@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 <cl...@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.
>
Re: Stopping a node from receiving any requests temporarily.
Posted by Callum Lamb <cl...@mintel.com>.
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 <cl...@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.