Apache Solr Reference Guide Covering Apache Solr 6.0

The level of redundancy built into the Collection and how fault tolerant the Cluster can be in the
event that some Nodes become unavailable.
The theoretical limit in the number concurrent search requests that can be processed under heavy
load.
Shards and Indexing Data in SolrCloud
When your data is too large for one node, you can break it up and store it in sections by creating one or more sh
ards. Each is a portion of the logical index, or core, and it's the set of all nodes containing that section of the
index.
A shard is a way of splitting a core over a number of "servers", or nodes. For example, you might have a shard
for data that represents each state, or different categories that are likely to be searched independently, but are
often combined.
Before SolrCloud, Solr supported Distributed Search, which allowed one query to be executed across multiple
shards, so the query was executed against the entire Solr index and no documents would be missed from the
search results. So splitting the core across shards is not exclusively a SolrCloud concept. There were, however,
several problems with the distributed approach that necessitated improvement with SolrCloud:
1.
2.
3.
Splitting of the core into shards was somewhat manual.
There was no support for distributed indexing, which meant that you needed to explicitly send documents
to a specific shard; Solr couldn't figure out on its own what shards to send documents to.
There was no load balancing or failover, so if you got a high number of queries, you needed to figure out
where to send them and if one shard died it was just gone.
SolrCloud fixes all those problems. There is support for distributing both the index process and the queries
automatically, and ZooKeeper provides failover and load balancing. Additionally, every shard can also have
multiple replicas for additional robustness.
In SolrCloud there are no masters or slaves. Instead, there are leaders and replicas. Leaders are automatically
elected, initially on a first-come-first-served basis, and then based on the Zookeeper process described at http://z
ookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection..
If a leader goes down, one of its replicas is automatically elected as the new leader. As each node is started, it's
assigned to the shard with the fewest replicas. When there's a tie, it's assigned to the shard with the lowest shard
ID.
When a document is sent to a machine for indexing, the system first determines if the machine is a replica or a
leader.
If the machine is a replica, the document is forwarded to the leader for processing.
If the machine is a leader, SolrCloud determines which shard the document should go to, forwards the
document the leader for that shard, indexes the document for this shard, and forwards the index notation
to itself and any replicas.
Document Routing
Solr offers the ability to specify the router implementation used by a collection by specifying the router.name p
arameter when creating your collection. If you use the " compositeId" router, you can send documents with a
prefix in the document ID which will be used to calculate the hash Solr uses to determine the shard a document
is sent to for indexing. The prefix can be anything you'd like it to be (it doesn't have to be the shard name, for
example), but it must be consistent so Solr behaves consistently. For example, if you wanted to co-locate
documents for a customer, you could use the customer name or ID as the prefix. If your customer is "IBM", for
example, with a document with the ID "12345", you would insert the prefix into the document id field:
"IBM!12345". The exclamation mark ('!') is critical here, as it distinguishes the prefix used to determine which
shard to direct the document to.
Apache Solr Reference Guide 6.0
548