Mastering Easysearch CCR: A Hands‑On Guide to Auto‑Follow

As an Easysearch/Elasticsearch operator or developer, you may have faced three painful scenarios: (1) difficulty achieving multi‑active deployments across regions, (2) high latency when users in one region access a remote cluster, and (3) complex manual failover procedures. Cross‑Cluster Replication (CCR) is presented as the ultimate solution, providing automated disaster recovery, multi‑active capabilities, and zero‑downtime migration.

1. Environment Preparation

Two servers simulate a production environment:

Leader cluster (master): 192.168.31.18:9300 Follower cluster (slave): 192.168.31.239:9300 Install Easysearch on both machines (installation steps omitted) and start the services. The startup logs show messages such as:

✅ Easysearch is ready to use! New Password: op1XXXXXXXXXXXXXXXX=lXA
✅ Easysearch is ready to use! New Password: gPDXXXXXXXXXXXXXXXw4fU
⚠️  Important: These initial passwords are valid only on first start; change them immediately in production.

2. Core Configuration – Establishing the Remote Cluster

On the follower cluster, execute the following request to let it "recognize" the leader:

PUT /_cluster/settings?pretty
{
  "persistent": {
    "cluster": {
      "remote": {
        "ccr_cluster": {
          "seeds": ["192.168.31.18:9300"]
        }
      }
    }
  }
}

Explanation:

ccr_cluster : alias for the leader cluster used in subsequent CCR commands.

seeds : address and transport port (9300, not the HTTP port 9200) of the leader.

persistent : makes the setting survive restarts.

Verify the connection with GET /_remote/info; a successful response containing the alias confirms the configuration.

3. Manual Replication – Quick CCR Core Demo

Create an index template and insert test documents on the leader:

PUT _index_template/logs-nginx-access
{
  "index_patterns": ["logs-nginx-access-*"],
  "priority": 500,
  "template": {
    "mappings": {
      "properties": {
        "@timestamp": {"type": "date"},
        "client_ip": {"type": "ip"},
        "status": {"type": "short"},
        "method": {"type": "keyword"},
        "bytes_sent": {"type": "long"}
      }
    }
  }
}
POST logs-nginx-access-2025.11.23/_doc
{ "@timestamp": "2025-11-23T12:34:56Z", "client_ip": "192.168.1.100", "status": 200, "method": "GET", "bytes_sent": 8572 }
POST logs-nginx-access-2025.11.24/_doc
{ "@timestamp": "2025-11-23T12:34:56Z", "client_ip": "192.168.1.100", "status": 200, "method": "GET", "bytes_sent": 8572 }

Start replication on the follower and verify that the documents appear, confirming that the first CCR copy succeeded.

4. Production‑Ready Feature – Auto‑Follow

What is Auto‑Follow? Define a rule so that every newly created index matching a pattern is automatically replicated without manual intervention.

Create an Auto‑Follow rule for all Nginx log indices:

POST /_replication/_autofollow?pretty
{
  "leader_alias": "ccr_cluster",
  "name": "nginx-logs-rule",
  "pattern": "logs-nginx-*",
  "use_roles": {
    "leader_cluster_role": "superuser",
    "follower_cluster_role": "superuser"
  }
}

Key parameters:

name : a meaningful rule identifier.

pattern : supports only prefix wildcards (e.g., logs-nginx-*); regular expressions are not allowed.

View configured rules with GET /_replication/autofollow_stats and delete a rule using:

DELETE /_replication/_autofollow
{
  "leader_alias": "ccr_cluster",
  "name": "nginx-logs-rule"
}

5. Security – Minimal‑Privilege Users

Never use admin or superuser for production replication. Easysearch provides two dedicated roles:

replication_leader : permissions required on the leader cluster.

replication_follower : permissions required on the follower cluster.

Create users with these roles on both clusters, then include the roles in CCR requests, e.g.:

{
  "use_roles": {
    "leader_cluster_role": "replication_leader",
    "follower_cluster_role": "replication_follower"
  }
}

6. Performance Tuning – Key Settings

Default settings work for most cases, but in bandwidth‑limited or latency‑sensitive environments adjust:

PUT _cluster/settings
{
  "persistent": {
    "replication.follower.metadata_sync_interval": "30s",
    "replication.autofollow.fetch_poll_interval": "10s",
    "replication.follower.index.ops_batch_size": 20000
  }
}

Increase ops_batch_size when bandwidth is ample but latency is high.

Increase interval values for cross‑country dedicated lines.

Decrease fetch_poll_interval for ultra‑real‑time requirements.

7. Common Pitfalls

Leader index deleted by ILM → follower enters PAUSED/FAILED (expected protection).

Follower index read‑only → must stop replication before writing.

Auto‑Follow only supports prefix wildcards; complex patterns like logs-2025 require manual rules or naming conventions.

Both clusters must run the same Easysearch/Elasticsearch version; even minor mismatches can cause issues.

Transport port for CCR is 9300, not the HTTP port 9200 – configure seeds accordingly.

8. Conclusion

Easysearch’s mature CCR feature enables:

Multi‑active deployments across regions (latency reduced ~80%).

Automated disaster recovery with near‑real‑time sync.

Read/write separation.

Zero‑downtime cluster migrations.

When combined with Auto‑Follow, role‑based security, and proper tuning, CCR becomes a core capability for large‑scale Easysearch/Elasticsearch architectures.