Apache Solr Reference Guide Covering Apache Solr 6.0

The goal of the project is to replicate data to multiple Data Centers. The initial version of the solution will cover
the active-passive scenario where data updates are replicated from a Source Data Center to a Target Data
Center. Data updates include adding/updating and deleting documents.
Data changes on the Source Data Center are replicated to the Target Data Center only after they are persisted
to disk. The data changes can be replicated in real-time (with a small delay) or could be scheduled to be sent in
intervals to the Target Data Center. This solution pre-supposes that the Source and Target data centers begin
with the same documents indexed. Of course the indexes may be empty to start.
Each shard leader in the Source Data Center will be responsible for replicating its updates to the appropriate
collection in the Target Data Center. When receiving updates from the Source Data Center, shard leaders in the
Target Data Center will replicate the changes to their own replicas.
This replication model is designed to tolerate some degradation in connectivity, accommodate limited bandwidth,
and support batch updates to optimize communication.
Replication supports both a new empty index and pre-built indexes. In the scenario where the replication is set
up on a pre-built index, CDCR will ensure consistency of the replication of the updates, but cannot ensure
consistency on the full index. Therefore any index created before CDCR was set up will have to be replicated by
other means (described in the section Starting CDCR the first time with an existing index) in order that Source
and Target indexes be fully consistent.
The active-passive nature of the initial implementation implies a "push" model from the Source collection to the
Target collection. Therefore, the Source configuration must be able to "see" the ZooKeeper ensemble in the
Target cluster. The ZooKeeper ensemble is provided configured in the Source's solrconfig.xml file.
CDCR is configured to replicate from collections in the Source cluster to collections in the Target cluster on a
collection-by-collection basis. Since CDCR is configured in solrconfig.xml (on both Source and Target
clusters), the settings can be tailored for the needs of each collection.
CDCR can be configured to replicate from one collection to a second collection within the same cluster. That is a
specialized scenario not covered in this document.
Glossary
Terms used in this document include:
Node: A JVM instance running Solr; a server.
Cluster: A set of Solr nodes managed as a single unit by a ZooKeeper ensemble, hosting one or more
Collections.
Data Center: A group of networked servers hosting a Solr cluster. In this document, the terms Cluster and
Data Center are interchangeable as we assume that each Solr cluster is hosted in a different group of
networked servers.
Shard: A sub-index of a single logical collection. This may be spread across multiple nodes of the cluster.
Each shard can have as many replicas as needed.
Leader: Each shard has one node identified as its leader. All the writes for documents belonging to a
shard are routed through the leader.
Replica: A copy of a shard for use in failover or load balancing. Replicas comprising a shard can either be
leaders or non-leaders.
Follower: A convenience term for a replica that is not the leader of a shard.
Collection: Multiple documents that make up one logical index. A cluster can have multiple collections.
Updates Log: An append-only log of write operations maintained by each node.
Architecture
Here is a picture of the data flow.
Apache Solr Reference Guide 6.0
610