You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by Saksham Gupta <sa...@indiamart.com.INVALID> on 2023/06/28 10:49:42 UTC
AutoWarming Solr Core before Adding to the Solr Cloud Cluster
Hi,
Is there a way of automwarming solr cores/shards before adding them to the
solr cloud cluster?
We are using solr cloud with a cluster of 8 nodes where each node consists
of 1 shard of a collection. It is very troublesome to restart a solr node
for some maintenance activity as it leads to multiple timeouts and 5xx. It
is due to internal requests coming from other nodes while this node is not
adequately autowarmed.
This leads to request timeouts and 5xxs.
To mitigate this issue:
1. Is there a way of autowarming solr cores without adding them to the
cluster?
2. Can we somehow stop the internal requests for a specific time?
Re: AutoWarming Solr Core before Adding to the Solr Cloud Cluster
Posted by Mikhail Khludnev <mk...@apache.org>.
Hello Saksham
1. I meant the later (client/code) level. I suppose it might be manipulated
via runtime properties. Right, it's enough hassle.
2. I never heard of making a replica inactive as well as informing Solr
about absence of update.
If you can make replica inactive for queries (a kind of shard.preference),
shard leaders may still handle updates.
Replicas on restarted nodes will be considered as delayed and were
recovered when node come back.
Giving all of that, it's easier just remove replicas from a recycled node,
but it will have to transfer all indices then.
Regarding warmup, searcher does it by itself. Perhaps useColdSearcher in
solrconfig.xml may adjust behavior as necessary.
On Mon, Jul 3, 2023 at 1:35 PM Saksham Gupta
<sa...@indiamart.com.invalid> wrote:
> Hi Mikhail,
> Thanks for the response.
> *1. How to maintain shards.preference parameter?* According to my
> understanding we can maintain shards.preference information at either solr
> level or at code level, both of which have downsides to them. If
> shards.pref is maintained at solr level we will need to reload collection
> leading to 5xx. If we do this at code level we will have to follow the
> release cycle which will increase the tat for this activity.
> *2. Is there a possibility to mark a replica inactive(after stopping
> indexing) so requests do not come to this replica? *We can stop indexing
> and mark a replica inactive for sometime and after the maintenance, we can
> autowarm it and mark it as active.
>
> On Thu, Jun 29, 2023 at 12:14 PM Mikhail Khludnev <mk...@apache.org> wrote:
>
> > Hello Saksham.
> > I think there's no quick answer for this.
> > a client can add this parameter to exclude a node from querying.
> > shards.preference=replica.location:http://server1,replica.location:
> > http://server2
> > But what can really stop shard queries is dropping replicas:
> >
> >
> https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#replacenode
> >
> >
> https://solr.apache.org/guide/solr/latest/deployment-guide/replica-management.html#movereplica
> > In your questions you're missing a potentially infinite stream of
> updates.
> > Even if you can ensure that there's no updates during node maintenance,
> > there's no way to give this promise to Solr cluster.
> > Approach for this problem described
> >
> >
> https://docs.cloudera.com/runtime/7.2.10/search-managing/topics/search-migrate-replicas.html
> > ?
> >
> >
> > On Wed, Jun 28, 2023 at 1:50 PM Saksham Gupta
> > <sa...@indiamart.com.invalid> wrote:
> >
> > > Hi,
> > >
> > > Is there a way of automwarming solr cores/shards before adding them to
> > the
> > > solr cloud cluster?
> > >
> > > We are using solr cloud with a cluster of 8 nodes where each node
> > consists
> > > of 1 shard of a collection. It is very troublesome to restart a solr
> node
> > > for some maintenance activity as it leads to multiple timeouts and 5xx.
> > It
> > > is due to internal requests coming from other nodes while this node is
> > not
> > > adequately autowarmed.
> > >
> > > This leads to request timeouts and 5xxs.
> > >
> > > To mitigate this issue:
> > >
> > > 1. Is there a way of autowarming solr cores without adding them to the
> > > cluster?
> > >
> > > 2. Can we somehow stop the internal requests for a specific time?
> > >
> >
> >
> > --
> > Sincerely yours
> > Mikhail Khludnev
> >
>
--
Sincerely yours
Mikhail Khludnev
Re: AutoWarming Solr Core before Adding to the Solr Cloud Cluster
Posted by Saksham Gupta <sa...@indiamart.com.INVALID>.
Hi Mikhail,
Thanks for the response.
*1. How to maintain shards.preference parameter?* According to my
understanding we can maintain shards.preference information at either solr
level or at code level, both of which have downsides to them. If
shards.pref is maintained at solr level we will need to reload collection
leading to 5xx. If we do this at code level we will have to follow the
release cycle which will increase the tat for this activity.
*2. Is there a possibility to mark a replica inactive(after stopping
indexing) so requests do not come to this replica? *We can stop indexing
and mark a replica inactive for sometime and after the maintenance, we can
autowarm it and mark it as active.
On Thu, Jun 29, 2023 at 12:14 PM Mikhail Khludnev <mk...@apache.org> wrote:
> Hello Saksham.
> I think there's no quick answer for this.
> a client can add this parameter to exclude a node from querying.
> shards.preference=replica.location:http://server1,replica.location:
> http://server2
> But what can really stop shard queries is dropping replicas:
>
> https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#replacenode
>
> https://solr.apache.org/guide/solr/latest/deployment-guide/replica-management.html#movereplica
> In your questions you're missing a potentially infinite stream of updates.
> Even if you can ensure that there's no updates during node maintenance,
> there's no way to give this promise to Solr cluster.
> Approach for this problem described
>
> https://docs.cloudera.com/runtime/7.2.10/search-managing/topics/search-migrate-replicas.html
> ?
>
>
> On Wed, Jun 28, 2023 at 1:50 PM Saksham Gupta
> <sa...@indiamart.com.invalid> wrote:
>
> > Hi,
> >
> > Is there a way of automwarming solr cores/shards before adding them to
> the
> > solr cloud cluster?
> >
> > We are using solr cloud with a cluster of 8 nodes where each node
> consists
> > of 1 shard of a collection. It is very troublesome to restart a solr node
> > for some maintenance activity as it leads to multiple timeouts and 5xx.
> It
> > is due to internal requests coming from other nodes while this node is
> not
> > adequately autowarmed.
> >
> > This leads to request timeouts and 5xxs.
> >
> > To mitigate this issue:
> >
> > 1. Is there a way of autowarming solr cores without adding them to the
> > cluster?
> >
> > 2. Can we somehow stop the internal requests for a specific time?
> >
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
Re: AutoWarming Solr Core before Adding to the Solr Cloud Cluster
Posted by Mikhail Khludnev <mk...@apache.org>.
Hello Saksham.
I think there's no quick answer for this.
a client can add this parameter to exclude a node from querying.
shards.preference=replica.location:http://server1,replica.location:
http://server2
But what can really stop shard queries is dropping replicas:
https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#replacenode
https://solr.apache.org/guide/solr/latest/deployment-guide/replica-management.html#movereplica
In your questions you're missing a potentially infinite stream of updates.
Even if you can ensure that there's no updates during node maintenance,
there's no way to give this promise to Solr cluster.
Approach for this problem described
https://docs.cloudera.com/runtime/7.2.10/search-managing/topics/search-migrate-replicas.html
?
On Wed, Jun 28, 2023 at 1:50 PM Saksham Gupta
<sa...@indiamart.com.invalid> wrote:
> Hi,
>
> Is there a way of automwarming solr cores/shards before adding them to the
> solr cloud cluster?
>
> We are using solr cloud with a cluster of 8 nodes where each node consists
> of 1 shard of a collection. It is very troublesome to restart a solr node
> for some maintenance activity as it leads to multiple timeouts and 5xx. It
> is due to internal requests coming from other nodes while this node is not
> adequately autowarmed.
>
> This leads to request timeouts and 5xxs.
>
> To mitigate this issue:
>
> 1. Is there a way of autowarming solr cores without adding them to the
> cluster?
>
> 2. Can we somehow stop the internal requests for a specific time?
>
--
Sincerely yours
Mikhail Khludnev