Apache Solr Reference Guide Covering Apache Solr 6.0

CDCR Configuration
In order to configure CDCR, the Source Data Center requires the host address of the ZooKeeper cluster
associated with the Target Data Center. The ZooKeeper host address is the only information needed by CDCR
to instantiate the communication with the Target Solr cluster. The CDCR configuration file on the Source cluster
will therefore contain a list of ZooKeeper hosts. The CDCR configuration file might also contain
secondary/optional configuration, such as the number of CDC Replicator threads, batch updates related settings,
etc.
CDCR Initialization
CDCR supports incremental upddates to either new or existing collections. CDCR may not be able to keep up
with very high volume updates, especially if there are significant communications latencies due to a slow "pipe"
between the data centers. Some scenarios:
There is an initial bulk load of a corpus followed by lower volume incremental updates. In this case, one
can do the initial bulk load, replicate the index and then keep then synchronized via CDCR. See the
section Starting CDCR the first time with an existing index for more information.
The index is being built up from scratch, without a significant initial bulk load. CDCR can be set up on
empty collections and keep them synchronized from the start.
The index is always being updated at a volume too high for CDCR to keep up. This is especially possible
in situations where the connection between the Source and Target data centers is poor. This scenario is
unsuitable for CDCR in its current form.
Inter-Data Center Communication
Communication between Data Centers will be achieved through HTTP and the Solr REST API using the SolrJ
client. The SolrJ client will be instantiated with the ZooKeeper host of the Target Data Center. SolrJ will manage
the shard leader discovery process.
Updates Tracking & Pushing
CDCR replicates data updates from the Source to the Target Data Center by leveraging the Updates Log.
A background thread regularly checks the Updates Log for new entries, and then forwards them to the Target
Data Center. The thread therefore needs to keep a checkpoint in the form of a pointer to the last update
successfully processed in the Updates Log. Upon acknowledgement from the Target Data Center that updates
have been successfully processed, the Updates Log pointer is updated to reflect the current checkpoint.
This pointer must be synchronized across all the replicas. In the case where the leader goes down and a new
leader is elected, the new leader will be able to resume replication from the last update by using this
synchronized pointer. The strategy to synchronize such a pointer across replicas will be explained next.
If for some reason, the Target Data Center is offline or fails to process the updates, the thread will periodically try
to contact the Target Data Center and push the updates.
Synchronization of Update Checkpoints
A reliable synchronization of the update checkpoints between the shard leader and shard replicas is critical to
avoid introducing inconsistency between the Source and Target Data Centers. Another important requirement is
that the synchronization must be performed with minimal network traffic to maximize scalability.
In order to achieve this, the strategy is to:
Uniquely identify each update operation. This unique identifier will serve as pointer.
Apache Solr Reference Guide 6.0
612