Elastic Cross-Cluster Replication: Leader/Follower, Auto-Follow, Disaster Recovery, and Non-Replicated Configuration

Learning outcomes

AtlasMart wants Region B to continue serving catalog searches when Region A is unavailable. Elastic CCR can maintain read-only follower indices, but it is an active-passive replication mechanism—not multi-master conflict resolution and not full-cluster configuration replication.

1. Active-passive means one write owner per replicated index

The leader index accepts application writes. A follower cluster creates a follower index that pulls operations from the leader. The follower is read-only while following. Initial creation uses remote recovery to copy Lucene segment files, then replication follows operation history retained through soft-delete retention leases.

# On follower cluster; remote alias already configured
PUT /atlasmart-products-dr-v1/_ccr/follow
{
  "remote_cluster": "region_a",
  "leader_index": "atlasmart-products-v1"
}

GET /atlasmart-products-dr-v1/_ccr/info
GET /atlasmart-products-dr-v1/_ccr/stats

# Direct application writes to the follower should fail while following.
POST /atlasmart-products-dr-v1/_doc/test
{"name":"should-not-write"}

A follower that falls behind beyond available operation history can require recreation. That is a recovery event, not a reason to expand retention blindly; size history and RPO together.

2. Auto-follow automates follower creation, not all DR configuration

Elastic auto-follow patterns create follower indices for newly created matching leader indices and can follow rolling data-stream backing indices. Existing followers remain when a pattern changes. Auto-follow does not turn templates, ILM/SLM policies, roles, cluster settings, repositories, or system indices into replicated state.

PUT /_ccr/auto_follow/atlasmart-catalog
{
  "remote_cluster": "region_a",
  "leader_index_patterns": ["atlasmart-products-*"],
  "follow_index_pattern": "{{leader_index}}"
}
GET /_ccr/auto_follow/atlasmart-catalog

Promote the non-data configuration through infrastructure-as-code or an explicit configuration release. Treat that release as independently testable and versioned.

3. What CCR replicates—and what it does not

Because security is independent, DR cannot be declared ready just because follower checkpoints are current. Application principals, TLS trust, templates, lifecycle rules, ingest pipelines, and routing expectations must be validated on the target cluster.

4. Measure lag as RPO evidence

RPO is the maximum acceptable data loss expressed in time or operations. CCR stats expose leader/follower checkpoints and operational state. Define a business RPO, then alarm before lag consumes that budget. Do not equate “follower task running” with “RPO met.”

GET /atlasmart-products-dr-v1/_ccr/stats

record:
leader_global_checkpoint=MEASURED
follower_global_checkpoint=MEASURED
operations_behind=MEASURED
last_successful_read=MEASURED
remote_recovery_state=MEASURED

rpo_gate: operations_behind <= DECLARED_BUDGET and follower is healthy

5. Failover is an application and write-ownership procedure

If Region A fails, do not immediately point writers at the follower while the old leader might still accept writes. First fence the old write path, verify lag against RPO, stop/pause the follow relationship as required, convert/unfollow according to the supported workflow, validate the target, then switch writes. The exact promotion sequence depends on version and topology and must be rehearsed.

1. Detect leader-region failure.
2. Fence old write endpoint / prove it cannot accept writes.
3. Read follower CCR stats; compare lag to RPO.
4. Validate security/config/templates/application smoke tests.
5. Promote/unfollow using supported APIs only.
6. Switch writes and reads.
7. Record data-loss window and RTO.
8. Rebuild replication before allowing a second failure domain.

6. Production judgment

Elastic CCR is valuable when AtlasMart can name a leader, accept asynchronous lag, and independently manage target-cluster configuration. It is not a snapshot replacement: snapshots protect against corruption/operator error and provide point-in-time recovery, while CCR quickly copies good and bad leader operations. Use both when recovery requirements justify both.

References

• Elastic remote clusters — Current connection, security-model, managed-environment, and remote-cluster guidance.
• Elastic remote-cluster connection modes — Sniff versus proxy semantics and network reachability.
• Elastic remote-cluster settings — skip_unavailable, roles, seeds, proxy settings, and defaults.
• Elastic cross-cluster search — Search syntax, optional clusters, response metadata, and supported APIs.
• Elastic cross-cluster replication — Active-passive mechanics, limitations, and DR patterns.
• Elastic auto-follow patterns — Rolling-index/data-stream follower automation.
• Elastic subscriptions — Current cross-cluster licensing boundaries; verify the deployed license before labs.
• OpenSearch cross-cluster search — Security flow, remote connections, permissions, and examples.
• OpenSearch cross-cluster replication — Replication plugin model and operational behavior.
• OpenSearch CCR getting started — Sniff/proxy connectivity, roles, follower startup, and pull replication.
• OpenSearch auto-follow — Pattern-based automatic replication.
• Amazon OpenSearch Service cross-cluster search — Managed-service connection and IAM/network restrictions.
• Amazon OpenSearch Service cross-cluster replication — Managed CCR constraints and domain connection workflow.