Apache Solr Reference Guide Covering Apache Solr 6.0

Each shard serves top-level query requests and then makes sub-requests to all of the other shards. Care should
be taken to ensure that the max number of threads serving HTTP requests is greater than the possible number
of requests from both top-level clients and other shards. If this is not the case, the configuration may result in a
distributed deadlock.
For example, a deadlock might occur in the case of two shards, each with just a single thread to service HTTP
requests. Both threads could receive a top-level request concurrently, and make sub-requests to each other.
Because there are no more remaining threads to service requests, the incoming requests will be blocked until the
other pending requests are finished, but they will not finish since they are waiting for the sub-requests. By
ensuring that Solr is configured to handle a sufficient number of threads, you can avoid deadlock situations like
this.
Prefer Local Shards
Solr allows you to pass an optional boolean parameter named preferLocalShards to indicate that a
distributed query should prefer local replicas of a shard when available. In other words, if a query includes prefe
rLocalShards=true, then the query controller will look for local replicas to service the query instead of
selecting replicas at random from across the cluster. This is useful when a query requests many fields or large
fields to be returned per document because it avoids moving large amounts of data over the network when it is
available locally. In addition, this feature can be useful for minimizing the impact of a problematic replica with
degraded performance, as it reduces the likelihood that the degraded replica will be hit by other healthy replicas.
Lastly, it follows that the value of this feature diminishes as the number of shards in a collection increases
because the query controller will have to direct the query to non-local replicas for most of the shards. In other
words, this feature is mostly useful for optimizing queries directed towards collections with a small number of
shards and many replicas. Also, this option should only be used if you are load balancing requests across all
nodes that host replicas for the collection you are querying, as Solr's CloudSolrClient will do. If not
load-balancing, this feature can introduce a hotspot in the cluster since queries won't be evenly distributed
across the cluster.
Read and Write Side Fault Tolerance
SolrCloud supports elasticity, high availability, and fault tolerance in reads and writes. What this means,
basically, is that when you have a large cluster, you can always make requests to the cluster: Reads will return
results whenever possible, even if some nodes are down, and Writes will be acknowledged only if they are
durable; i.e., you won't lose data.
Read Side Fault Tolerance
In a SolrCloud cluster each individual node load balances read requests across all the replicas in 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 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 rel
evant 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.
zkConnected
A Solr node will return the results of a search request as long as it can communicate with at least one replica of
Apache Solr Reference Guide 6.0
553