Apache Solr Reference Guide Covering Apache Solr 6.0

updateRequestProcessorChains and updateProcessors
Update processors in SolrCloud
In a single node, stand alone Solr, each update is run through all the update processors in a chain exactly once.
But the behavior of update request processors in SolrCloud deserves special consideration.
A critical SolrCloud functionality is the routing and distributing of requests – for update requests this routing is
implemented by the DistributedUpdateRequestProcessor, and this processor is given a special status by Solr
due to its important function.
In a distributed SolrCloud situation setup, All processors in the chain before the DistributedUpdateProcessor are
run on the first node that receives an update from the client, regardless of this nodes status as a leader or
replica. The DistributedUpdateProcessor then forwards the update to the appropriate shard leader for the
update (or to multiple leaders in the event of an update that affects multiple documents, such as a delete by
query, or commit). The shard leader uses a transaction log to apply Atomic Updates & Optimistic Concurrency a
nd then forwards the update to all of the shard replicas. The leader and each replica run all of the processors in
the chain that are listed after the DistributedUpdateProcessor.
For example, consider the "dedupe" chain which we saw in a section above. Assume that a 3 node SolrCloud
cluster exists where node A hosts the leader of shard1, node B hosts the leader of shard2 and node C hosts the
replica of shard2. Assume that an update request is sent to node A which forwards the update to node B
(because the update belongs to shard2) which then distributes the update to its replica node C. Let's see what
happens at each node:
In summary:
1.
2.
Node A: Runs the update through the SignatureUpdateProcessor (which computes the signature and puts
it in the "id" field), then LogUpdateProcessor and then DistributedUpdateProcessor. This processor
determines that the update actually belongs to node B and is forwarded to node B. The update is not
processed further. This is required because the next processor which is RunUpdateProcessor will execute
the update against the local shard1 index which would lead to duplicate data on shard1 and shard2.
Node B: Receives the update and sees that it was forwarded by another node. The update is directly sent
to DistributedUpdateProcessor because it has already been through the SignatureUpdateProcessor on
node A and doing the same signature computation again would be redundant. The DistributedUpdateProc
essor determines that the update indeed belongs to this node, distributes it to its replica on Node C and
then forwards the update further in the chain to RunUpdateProcessor.
Node C: Receives the update and sees that it was distributed by its leader. The update is directly sent to
DistributedUpdateProcessor which performs some consistency checks and forwards the update further in
the chain to RunUpdateProcessor.
All processors before DistributedUpdateProcessor are only run on the first node that receives an update
request whether it be a forwarding node (e.g. node A in the above example) or a leader (e.g. node B). We
call these pre-processors or just processors.
All processors after DistributedUpdateProcessor run only on the leader and the replica nodes. They are
not executed on forwarding nodes. Such processors are called "post-processors".
In the previous section, we saw that the updateRequestProcessorChain was configured with processor="rem
ove_blanks, signature". This means that such processors are of the #1 kind and are run only on the
forwarding nodes. Similarly, we can configure them as the #2 kind by specifying with the attribute
"post-processor" as follows:
Apache Solr Reference Guide 6.0
461