anchor.diff:  
   The client can specify '<<distributed-search-with-index-sharding.adoc#distributed-search-with-index-sharding,`shards.info`>>' along with the `shards.tolerant` parameter to retrieve more fine-grained details.
   
  -Example response with `partialResults` flag set to 'true':
  +Example response with `partialResults` flag set to `true`:
   
   .Solr Response with partialResults
   [source,json]
  
positive.code: }
  ----
  
  === The collection Parameter
  This parameter allows you to specify a collection or a number of collections on which the query should be executed. This allows you to query multiple collections at once and all the feature of Solr which work in a distributed manner can work across collections.
  
  [source,java]
  ----
  http://localhost:8983/solr/collection1/select?collection=collection1,collection2,collection3
  ----
  
  === The \_route_ Parameter
  
  This parameter can be used to specify a route key which is used to figure out the corresponding shards. For example, if you have a document with a unique key "user1!123", then specifying the route key as "_route_=user1!" (notice the trailing '!' character) will route the request to the shard which hosts that user. You can specify multiple such route keys separated by comma.
  This parameter can be leveraged when we have shard data by users. See '<<shards-and-indexing-data-in-solrcloud.adoc#document-routing,`Document Routing`>>' for more information
  
  [source,java]
  ----
  http://localhost:8983/solr/collection1/select?q=*:*&_route_=user1!
  http://localhost:8983/solr/collection1/select?q=*:*&_route_=user1!,user2!
  ----
  
  == Distributed Tracing and Debugging Parameters
  
  There are several distributed tracing parameters which can be used to trace the request as well as find timing information for a distributed request.
  
  [width="100%",cols="50%,50%",options="header",]
  |===
  |Parameter |Description
  |debug=track | Gives debug information for each phase of the distributed query.
  |===
  
  == Optimizations and Related Parameters
  
  The table below summarizes the general parameters for controlling routing.
  
  [width="100%",cols="50%,50%",options="header",]
  |===
  |Parameter |Description
  |distrib.singlePass |Set to true to fetch stored fields from all shards in a single pass.
  |===
  
  These parameters are described in the sections below.
  
  === The distrib.singlePass Parameter
  
  If set to "true," this parameter changes the distributed search algorithm to fetch all requested stored fields from each shard in the first phase itself. This eliminates the need for making a second request to fetch the stored fields. This can be faster when requesting a very small number of fields containing small values. However, if large fields are requested or if a lot of fields are requested then the overhead of fetching them over the network from all shards can make the request slower as compared to the normal distributed search path.
  
  Note that this optimization only applies to distributed search. Certain features such as faceting may make additional network requests for refinements etc.
  
negative.code: 
  == Read Side Fault Tolerance
  
  In a SolrCloud cluster each individual node load balances read requests across all the replicas in a collection. You still need a load balancer on the 'outside' that talks to the cluster, or you need a smart client which understands how to read and interact with Solr's metadata in ZooKeeper and only requests the ZooKeeper ensemble's address to start discovering to which nodes it should send requests. (Solr provides a smart Java SolrJ client called {solr-javadocs}/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html[CloudSolrClient].)
  
  Even if some nodes in the cluster are offline or unreachable, a Solr node will be able to correctly respond to a search request as long as it can communicate with at least one replica of every shard, or one replica of every _relevant_ shard if the user limited the search via the `shards` or `\_route_` parameters. The more replicas there are of every shard, the more likely that the Solr cluster will be able to handle search results in the event of node failures.
  
  == Query Parameters for Query Routing
  
  === zkConnected Parameter
  
  A Solr node will return the results of a search request as long as it can communicate with at least one replica of every shard that it knows about, even if it can _not_ communicate with ZooKeeper at the time it receives the request. This is normally the preferred behavior from a fault tolerance standpoint, but may result in stale or incorrect results if there have been major changes to the collection structure that the node has not been informed of via ZooKeeper (i.e., shards may have been added or removed, or split into sub-shards).
  
  