Apache Solr Reference Guide Covering Apache Solr 6.0

200
As shown in the example above, the processor will return 200 to the client but will ignore the commit / optimize
request. Notice that you need to wire-in the implicit processors needed by SolrCloud as well, since this custom
chain is taking the place of the default chain.
In the following example, the processor will raise an exception with a 403 code with a customized error message:
403
Thou shall not issue a commit!
Lastly, you can also configure it to just ignore optimize and let commits pass thru by doing:
Thou shall not issue an optimize, but commits are
OK!
true
Distributed Requests
When a Solr node receives a search request, that request is routed behinds the scenes to a replica of some
shard that is part of the collection being searched. The chosen replica will act as an aggregator: creating internal
requests to randomly chosen replicas of every shard in the collection, coordinating the responses, issuing any
subsequent internal requests as needed (For example, to refine facets values, or request additional stored fields)
and constructing the final response for the client.
Limiting Which Shards are Queried
One of the advantages of using SolrCloud is the ability to very large collections distributed among various shards
– but in some cases you may know that you are only interested in results from a subset of your shards. You
have the option of searching over all of your data or just parts of it.
Querying all shards for a collection should look familiar; it's as though SolrCloud didn't even come into play:
Apache Solr Reference Guide 6.0
550