I know you're asking about nodes, not replicas; but depending on what you're trying to achieve you might be as well off routing requests based on replica. Have you considered the various options available via the `shards.preference` param [1]? For instance, you could set up your "write" replicas as `NRT`, and your "read" replicas as `PULL`, then use the `replica.type` property of the `shards.preference` param to route "select" requests to the `PULL` replicas.
It might also be worth looking at the options for stable routing provided by the relatively new `replica.base` property (of `shards.preference` param). If you have varying workloads with distinct cache usage patterns, for instance, this could be useful to you. To tie this back to nodes (your original question, if a replica-focused solution is not sufficient): you could still use replica types and the `shards.preference` param to control request routing, and implicitly route by node by paying extra attention to careful replica placement on particular nodes. As it happens, I'm actually doing a very simple variant of this -- but not in a general-purpose enough way to feel I'm in a position to make any specific recommendations. [1] https://lucene.apache.org/solr/guide/8_7/distributed-requests.html#shards-preference-parameter On Fri, Jan 15, 2021 at 9:56 AM Doss <itsmed...@gmail.com> wrote: > Dear All, > > 1. Suppose we have 10 node SOLR Cloud setup, is it possible to dedicate 4 > nodes for writes and 6 nodes for selects? > > 2. We have a SOLR cloud setup for our customer facing applications, and we > would like to have two more SOLR nodes for some backend jobs. Is it good > idea to form these nodes as slave nodes and making one node in the cloud as > Master? > > Thanks! > Mohandoss. >
