Apache Solr Reference Guide Covering Apache Solr 6.0

Updates and deletes are first written to the Source cluster, then forwarded to the Target cluster. The data flow
sequence is:
1.
2.
3.
4.
5.
6.
A shard leader receives a new data update that is processed by its Update Processor.
The data update is first applied to the local index.
Upon successful application of the data update on the local index, the data update is added to the
Updates Log queue.
After the data update is persisted to disk, the data update is sent to the replicas within the Data Center.
After Step 4 is successful CDCR reads the data update from the Updates Log and pushes it to the
corresponding collection in the Target Data Center. This is necessary in order to ensure consistency
between the Source and Target Data Centers.
The leader on the Target data center writes the data locally and forwards it to all its followers.
Steps 1, 2, 3 and 4 are performed synchronously by SolrCloud; Step 5 is performed asynchronously by a
background thread. Given that CDCR replication is performed asynchronously, it becomes possible to push
batch updates in order to minimize network communication overhead. Also, if CDCR is unable to push the
update at a given time -- for example, due to a degradation in connectivity -- it can retry later without any impact
on the Source Data Center.
One implication of the architecture is that the leaders in the Source cluster must be able to "see" the leaders in
the Target cluster. Since leaders may change, this effectively means that all nodes in the Source cluster must be
able to "see" all Solr nodes in the Target cluster so firewalls, ACL rules, etc. must be configured with care.
Major Components
There are a number of key features and components in CDCR’s architecture:
Apache Solr Reference Guide 6.0
611