Hi,
The use case for this is that our indexing node has more shards than it has CPU
cores it is enough for indexing, but not enough to serve the search queries if
those queries are heavy. To put it out of serving requests we are using
in-house solution that routes the queries to pull replicas
I've now posted https://issues.apache.org/jira/browse/SOLR-11982 with a
patch. It works just like preferLocalShards. SOLR-10880 is awesome, but
my idea is not to filter out anything, so this just adjusts the order of
nodes.
--Ere
Tomas Fernandez Lobbe kirjoitti 8.1.2018 klo 21.42:
This
This feature is not currently supported. I was thinking in implementing it by
extending the work done in SOLR-10880. I still didn’t have time to work on it
though. There is a patch for SOLR-10880 that doesn’t implement support for
replica types, but could be used as base.
Tomás
> On Jan 8,
Server load alone doesn't always indicate the server's ability to serve
queries. Memory and cache state are important too, and they're not as
easy to monitor. Additionally, server load at any single point in time
or a short term average is not indicative of the server's ability to
handle
Interesting indeed, but maybe in line with the idea that ES knows what
to do best without the user interfering.
My example parameter name was bad, it should have been something like
"preferReplicaTypes=TLOG,PULL". I can't see what would be bad about
that, but then to me it seems Solr has
Actually, I think a much better option is to route queries to server load.
The theory of preferring pull replicas to leaders would be that the leader
will be doing the indexing work and the pull replicas would be doing less
work therefore serving queries faster. But that's a fragile assumption.
It is interesting that ES had similar feature to prefer primary/replica but it
deprecating that and will remove it - could not find explanation why.
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/
> On
Hi,
It would be really nice to have a server-side option, though. Not
everyone uses Solrj, and a typical fairly dummy client just queries the
server without any understanding about shards etc. Solr could be clever
enough to not forward the query to NRT shards when configured to prefer
PULL
Hi Stanislav,
I don’t think that there is a built in feature to do this, but that sounds like
nice feature of Solrj - maybe you should check if available. You can implement
it outside of Solrj - check cluster state to see which shards are available and
send queries only to pull replicas.
HTH,
Hi,
We have a Solr 7.1 setup with SolrCloud where we have multiple shards on one
server (for indexing) each shard has a pull replica on other servers.
What are the possible ways to limit search request only to pull type replicase?
At the moment the only solution I found is to append shards
10 matches
Mail list logo
