Elasticsearch Cross-Cluster Replication Setup

Imagine you have two data centers in different regions, and you need search to work with minimal latency from any location. Or you're building Disaster Recovery with an RTO of less than a minute and an RPO of 30 seconds. Cross-Cluster Replication (CCR) in Elasticsearch is not a backup or failover "out of the box", but an active one-way replication: all changes in the leader index are automatically reproduced in the follower index on a remote cluster. We configure CCR turnkey: from audit to documentation and training. Over 50 Elasticsearch projects in 5 years allow us to guarantee results.

Why is Cross-Cluster Replication (CCR) needed?

CCR solves three scenarios: geo-distribution of search (read from the nearest cluster), Disaster Recovery with automatic failover, and read-scaling (offloading leader). Unlike snapshot/restore, replication lag is seconds, not minutes. Savings from implementing CCR can reach 70% on operational costs compared to manual recovery. Our clients save up to 80% of setup time thanks to ready configurations.

How Does CCR Work Internally?

The follower index on the target cluster constantly reads operations from the translog of the leader index via a special API. This is not snapshotting—changes are replicated in near real time (lag is typically 2-5 seconds, depending on network). Requirements: both clusters on the same major version (with some exceptions for minor) and a Basic license or higher (Basic is sufficient from Elasticsearch 7.8+). The official Elasticsearch guide describes this in detail.

The first step is configuring the remote cluster on the follower cluster:

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote.leader-cluster.seeds": [
      "es-master-01.leader.internal:9300",
      "es-master-02.leader.internal:9300",
      "es-master-03.leader.internal:9300"
    ],
    "cluster.remote.leader-cluster.transport.ping_schedule": "30s"
  }
}

Check connectivity. If connected: true, you can create a follower index.

How to Create a Follower Index and Auto-Follow?

For a single index:

PUT /follower-logs-000001/_ccr/follow
{
  "remote_cluster": "leader-cluster",
  "leader_index": "logs-000001",
  "settings": {
    "index.number_of_replicas": 1
  },
  "max_read_request_operation_count": 5120,
  "max_outstanding_read_requests": 12,
  "max_read_request_size": "32mb",
  "max_write_request_operation_count": 5120,
  "max_write_buffer_count": 512,
  "max_retry_delay": "500ms",
  "read_poll_timeout": "1m"
}

For automatic replication of all new indices matching a pattern—Auto-follow pattern:

PUT /_ccr/auto_follow/logs-pattern
{
  "remote_cluster": "leader-cluster",
  "leader_index_patterns": ["logs-*"],
  "follow_index_pattern": "{{leader_index}}",
  "settings": {
    "index.number_of_replicas": 1
  }
}

With auto-follow, every new index on the leader cluster matching the pattern automatically gets a follower on the target cluster. This is critical when using ILM rollover—without auto-follow you would have to manually create a follower for each new index after rollover.

Why Does Integrating CCR with ILM Cause Problems?

The most common issue when configuring CCR on top of ILM is that ILM on the leader cluster performs rollover and shrink, and the follower cluster doesn't have time to replicate data before the index moves to warm/freeze. The follower index then "lags" and gets stuck. The solution is to use CCR pause before shrink on the leader, or configure wait_for_data_replication_timeout in the ILM policy on the leader cluster. Alternatively, keep the follower in a "hot" state longer by applying a separate ILM policy only on the follower cluster.

On the follower cluster, the index is read-only by default. Before switching the application to the follower (in case of disaster recovery), you need to promote it to a regular index:

POST /follower-logs-000001/_ccr/unfollow 

After that, the index becomes a normal writable index, but replication from the leader stops.

How to Monitor Replication?

GET /follower-logs-000001/_ccr/stats 

Check follower_global_checkpoint vs leader_global_checkpoint—the difference shows the lag in operations. If the gap grows, there is a network or follower node performance issue. Prometheus alerts via elasticsearch-exporter:

• elasticsearch_ccr_follower_operations_written should be constantly increasing (normally > 100 ops/s)
• elasticsearch_ccr_follower_time_since_last_read_millis > 60000 — replication has stopped

Typical Difficulties When Setting Up CCR

CCR requires both clusters to be accessible via the transport port (9300). In the cloud, this means VPN or VPC Peering between regions—not simply opening port 443. Latency between clusters directly affects replication lag. During large initial replication (hundreds of GB), the follower index goes through a recovery phase via snapshot—this is slower than transactional replication. This must be considered when planning the initial synchronization window (typically 1-2 hours per 100 GB).

Comparison of CCR with Other Approaches

CCR outperforms snapshot/restore by 10-100 times in RTO and RPO, but requires properly configured network and ILM integration.

Network Requirements for CCR

What's Included in the Work

Process and Timeline

Setting up CCR from scratch between two clusters takes 2-3 days: configuring remote cluster, checking network and TLS, creating auto-follow patterns, integrating with ILM, testing failover (promote follower → switch traffic → rollback). If the cluster doesn't exist yet, add time for its deployment (1-2 days).

The cost is calculated individually after auditing the current clusters and RTO/RPO requirements. Contact us for a consultation—we'll send a commercial proposal within the day. Reach out to get a transparent estimate for your project. Get in touch to discuss details.