Apache Solr Reference Guide Covering Apache Solr 6.0

elow is legacy and was used prior to the existence of SolrCloud. SolrCloud provides for a truly distributed set of
features with support for things like automatic routing, leader election, optimistic concurrency and other sanity
checks that are expected out of a distributed system.
Everything on this page is specific to legacy setup of distributed search. Users trying out SolrCloud should not
follow any of the steps or information below.
Update reorders (i.e., replica A may see update X then Y, and replica B may see update Y then X). deleteByQu
ery also handles reorders the same way, to ensure replicas are consistent. All replicas of a shard are consistent,
even if the updates arrive in a different order on different replicas.
Distributing Documents across Shards
When not using SolrCloud, it is up to you to get all your documents indexed on each shard of your server farm.
Solr supports distributed indexing (routing) in it's true form only in the SolrCloud mode.
In the legacy distributed mode, Solr does not calculate universal term/doc frequencies. For most large-scale
implementations, it is not likely to matter that Solr calculates TF/IDF at the shard level. However, if your collection
is heavily skewed in its distribution across servers, you may find misleading relevancy results in your searches.
In general, it is probably best to randomly distribute documents to your shards.
Executing Distributed Searches with the shards Parameter
If a query request includes the shards parameter, the Solr server distributes the request across all the shards
listed as arguments to the parameter. The shards parameter uses this syntax:
host
: port / base_url [, host : port / base_url ]*
For example, the shards parameter below causes the search to be distributed across two Solr servers: solr1 an
d solr2, both of which are running on port 8983:
http://localhost:8983/solr/core1/select?shards=solr1:8983/solr/core1,solr2:8983/so
lr/core1&indent=true&q=ipod+solr
Rather than require users to include the shards parameter explicitly, it is usually preferred to configure this
parameter as a default in the RequestHandler section of solrconfig.xml.
Do not add the shards parameter to the standard requestHandler; otherwise, search queries may enter
an infinite loop. Instead, define a new requestHandler that uses the shards parameter, and pass
distributed search requests to that handler.
Currently, only query requests are distributed. This includes requests to the standard request handler (and
subclasses such as the DisMax RequestHandler), and any other handler (org.apache.solr.handler.comp
onent.searchHandler) using standard components that support distributed search.
As in SolrCloud mode, when shards.info=true, distributed responses will include information about the
shard (where each shard represents a logically different index or physical location)
The following components support distributed search:
The Query component, which returns documents matching a query
The Facet component, which processes facet.query and facet.field requests where facets are sorted by
count (the default).
The Highlighting component, which enables Solr to include "highlighted" matches in field values.
The Stats component, which returns simple statistics for numeric fields within the DocSet.
The Debug component, which helps with debugging.
Apache Solr Reference Guide 6.0
626