We start with the words in the name, because each one carries part of the meaning.

Cluster, Replication and Cross

A cluster is a group of Elasticsearch servers, called nodes, that work together and share the job of storing and searching data. Replication means keeping copies of the same data in more than one place. Cross-cluster means the copies live in different clusters, not just on different servers of the same cluster.

Put together, Cross-Cluster Replication is an Elasticsearch feature that automatically copies indices from one cluster to another and keeps the copy up to date as the original changes. An index is the basic container for documents in Elasticsearch, a bit like a table in a database. So CCR copies whole indices, continuously, from a source cluster to a target cluster.

Leader and Follower

CCR uses two simple roles. The index that gets changed by applications is the leader index, and it lives in the leader cluster. The copy is the follower index, and it lives in the follower cluster. The follower watches the leader and copies every change. The follower never changes the leader.

Three Words to Remember

• Asynchronous: the leader does not wait for the follower. It saves the data locally, tells the application “done”, and the follower catches up a moment later.
• Pull-based: the follower asks the leader for new changes. The leader does not push anything out.
• Read-only copy: applications can search the follower, but they cannot write to it while it is following.

What CCR Is Not

CCR is not a backup. If someone deletes an index by mistake on the leader, that deletion is copied to the follower too, because the follower faithfully copies everything. CCR is also not a way to write to two clusters at once for the same index. And it is not the same as searching several clusters together, which is a different feature called cross-cluster search. We will compare all of these later.

Elasticsearch already keeps copies of your data. To see why we need CCR as well, we must understand what those copies protect against and what they cannot.

Shards and Replicas Inside a Cluster

An index is split into pieces called shards, and shards are spread across the nodes of a cluster. Each shard normally has one or more replica shards, which are extra copies placed on different nodes. If one node crashes, a replica on another node takes over, and no data is lost. This is Elasticsearch’s everyday safety net, and it works very well for single-machine failures.

Where the Safety Net Ends

All those replicas still live inside one cluster, usually in one data center or one cloud region. That means they share the same fate in several situations:

• Site failure: a fire, flood, power cut or network outage at the data center takes every node down together.
• Regional cloud outage: a problem in one cloud region can affect all zones or the services they rely on.
• Distance: users far from the cluster always pay the price of long network trips, no matter how many replicas exist.
• Rules about location: some laws and contracts require data to stay in a certain country or to be served from inside it.
• Growth of many small clusters: an organization with dozens of separate clusters at branches or factories has no built-in way to see all their data in one place.

Why Not Just Stretch One Cluster Across Regions?

A natural idea is to place some nodes of one big cluster in Frankfurt and others in Virginia. Elasticsearch is not designed for this. Nodes in one cluster talk to each other constantly and expect fast, steady links. Across continents the delay is high and the network can wobble. A cluster spread this way can become slow, unstable, or unable to agree on who is in charge when the link between regions breaks. Elastic’s guidance is to keep a cluster within one low-latency location and to use CCR to connect separate clusters.

A few terms appear in every CCR discussion. Learn them here and the later chapters will feel easy.

Two Clusters, One Direction

flowchart LR
    APP["Applications writing data"] --> L["Leader cluster: leader index"]
    L -. "changes pulled over the network" .-> F["Follower cluster: follower index"]
    F --> READ["Applications searching nearby"]

The dotted arrow is the heart of CCR. It is drawn from the leader toward the follower, but remember who starts the conversation: the follower reaches out and pulls. That design makes the leader simpler, because it does not have to keep track of every place its data should be pushed to.

Why the Numbering Matters

Every change on a shard gets a sequence number, counted upward like the page numbers of a diary: 1, 2, 3, and so on. Because of this, a follower can say precisely, “I have everything up to number 4,200. Please send me 4,201 onward.” There is no guessing and no need to compare whole indices. This tiny idea is what makes continuous copying both accurate and efficient.

Systems copy data in several different ways. Knowing the options explains why CCR was designed the way it was.

Synchronous or Asynchronous

In synchronous replication, the system does not tell the application “saved” until every copy, including the faraway one, confirms it. This gives strong safety, because no confirmed write can be lost. But every write must wait for the slowest, farthest copy. Across continents, that delay is painful, and if the far link breaks, writes may stall completely.

In asynchronous replication, the system confirms the write after saving locally, and copies to the far site afterward. Writes stay fast and keep working even when the far link is down. The price is a small window during which the far copy is slightly behind. CCR chooses this style.

Push or Pull

In a push design, the source sends changes to each destination. In a pull design, each destination asks the source. CCR is pull-based. The follower decides how fast to read, how much to read at once and when to retry after a failure, which naturally protects the leader from being overwhelmed.

Let us open the box and look at the parts that make CCR work, from the user’s browser all the way to the shards.

The Parts of the System

flowchart TD
    U["Users on web and mobile"] --> G["API Gateway"]
    G --> LB["Load Balancer"]
    LB --> IS["Indexing Service"]
    LB --> SS["Search Service"]
    IS --> LC["Leader Cluster: coordinating node"]
    LC --> LP["Leader primary shards"]
    LP --> LR["Leader replica shards"]
    RC["Remote cluster connection with TLS and credentials"]
    FT["Follower shard tasks"] --> RC
    RC --> LP
    FT --> FP["Follower primary shards"]
    FP --> FR["Follower replica shards"]
    SS --> LC
    SS -. "nearby reads" .-> FC["Follower Cluster: coordinating node"]
    FC --> FP
    MON["Monitoring: lag, errors, stats"] --> FT

Reading the Diagram

Follow the top of the picture first. Users reach the gateway and load balancer, which hand requests to the indexing service and the search service. The indexing service sends writes to the leader cluster. There, a coordinating node routes each write to the right primary shard, which copies it to its replicas inside the same cluster.

Now look at the follower side. For each follower shard there is a background shard follow task. This task reads changes from the leader’s primary shard through the secured remote cluster connection. It then writes those changes into its own follower primary shard, which copies them to follower replicas. The search service can send reads to the follower cluster when the follower is closer to the user. Monitoring watches the follow tasks, since they carry the health of the entire copy.

Follow one document from the moment an application saves it to the moment it is searchable in the follower cluster.

sequenceDiagram
    participant App as Application
    participant LP as Leader primary shard
    participant LR as Leader replica shard
    participant FT as Follower shard task
    participant FP as Follower primary shard
    App->>LP: Index a document
    LP->>LP: Assign sequence number and store change
    LP->>LR: Copy change to replica
    LR-->>LP: Confirm
    LP-->>App: Write acknowledged
    FT->>LP: Ask for changes after my last checkpoint
    LP-->>FT: Send batch of changes
    FT->>FP: Apply changes with same sequence numbers
    FP-->>FT: Confirm and advance checkpoint

Why the Leader Must Remember History

The leader can only hand out changes that it still remembers. Elasticsearch keeps this history using a feature called soft deletes. Normally, when a document is deleted or updated, the old version simply disappears at some point. With soft deletes, the shard keeps a lightweight record of recent operations, including deletions, so that followers can read them later.

To avoid keeping history forever, Elasticsearch uses retention leases. Each follower holds a lease on the leader shard that says “please keep everything after my checkpoint.” The follower renews the lease as it reads. If a follower disappears for too long, its lease expires, by default after about twelve hours, and the leader is free to discard old history.

A new follower cannot begin by reading a live stream of changes, because it is missing everything that happened before. It first needs a full starting copy.

Two Phases: Copy, Then Follow

When you create a follower index for an existing leader index, two phases happen. In the first phase, called remote recovery, the follower copies the leader’s data files over the network, much as a replica shard would recover from its primary. This gives the follower a snapshot of the leader as it looked at one moment.

In the second phase, the follower switches to following. It asks for every operation that happened after the moment of the snapshot, applies them, and from then on keeps reading new operations continuously. Sequence numbers make the hand-off exact, so nothing is missed and nothing is applied twice.

The Cost of the First Copy

For a large index, the first phase can move hundreds of gigabytes or even terabytes across the network. This takes time and uses bandwidth on both sides. Elasticsearch limits the speed of this recovery by default, so it does not swamp the leader’s network or slow its normal work. You can tune that limit, but remember that a faster copy uses more of the leader’s resources at the same moment it is serving real users.

Planning the Start

Plan bootstrapping like a move to a new house. Schedule it for a quiet time, check that the network link has enough room, and make sure the follower cluster has enough disk space for the full copy plus its own replicas. Start with the most important indices first, and add others in waves rather than all at once. Watch the recovery progress and the leader’s load while it runs.

Setting up CCR follows a clear order. Each step depends on the one before it.

Two Ways to Create Followers

You can create followers by hand, one index at a time, which suits a few long-lived indices such as a product catalog. Or you can define an auto-follow pattern, which suits indices that appear over time, such as one new log index each day. We look at auto-follow in the next chapter.

Using Kibana or the API

Elasticsearch exposes all of these steps through its programming interface, so they can be automated with scripts and infrastructure tools. Kibana also has a management screen for cross-cluster replication, where you can register remote clusters, create followers and auto-follow patterns, and see their status. Small teams often start with the screen to learn the concepts, and move to automation once the design is stable.

Many real systems create new indices all the time. Creating each follower by hand would be tiring and easy to forget, so Elasticsearch can do it for you.

The Problem With Rolling Indices

Log and metric systems usually write to a new index every day or whenever the current one gets big. A team might have indices named like “logs-web-2026.09.21”, then “logs-web-2026.09.22”, and so on. If you had to create a follower for each new index by hand, someone would eventually forget, and the follower cluster would silently miss a day of data. That gap would only be discovered during a disaster, the worst possible moment.

What an Auto-Follow Pattern Does

An auto-follow pattern is a standing instruction stored on the follower cluster. It names a remote cluster and one or more name patterns with wildcards, such as “logs-web-*”. Elasticsearch checks the leader cluster regularly. Whenever it finds a new index whose name matches, it creates a follower index for it, following all the usual steps automatically. You can also decide how follower indices should be named, for example by adding a prefix that shows where they came from.

Data Streams

A data stream is a newer Elasticsearch structure for time-based data such as logs and metrics. Behind one name, it manages a series of hidden backing indices and creates new ones as the old ones fill up. CCR can follow data streams through auto-follow patterns, which is the recommended way to replicate time-series data. New backing indices are picked up automatically, and the follower cluster ends up with a matching data stream that readers can query by its name.

Because CCR is asynchronous, the follower is always slightly behind. This chapter explains exactly what is guaranteed and what is not.

Eventually Consistent

A system is eventually consistent when copies may differ for a short time, but all copies will become the same once the changes have arrived. That is the promise of CCR. If writes to the leader stopped right now, the follower would soon hold exactly the same data.

In practice this means that a document indexed on the leader a second ago might not yet be visible in the follower. During that moment, a search on the follower gives an answer that was true a short while earlier. Most search use cases accept this happily, since a product added two seconds ago missing from a far-away search is rarely a problem.

Order Is Preserved Per Shard

Each follower shard applies operations from its leader shard in sequence-number order, so the story of each individual document is told in the right order. If a document was created, updated twice and then deleted, the follower sees those events in that order and ends in the same state as the leader.

Across different shards, however, the follower does not keep a global order. Shard 1 may be a little further ahead than shard 2. A search that touches both could briefly see a mix in which shard 1 has a change that shard 2 does not yet have. For related documents that live on different shards, this can produce a momentary inconsistency.

What You Cannot Assume

• No read-your-own-writes on the follower. An application that writes to the leader and immediately reads the same data from the follower may not find it yet. Read from the leader when freshness matters.
• No zero data loss on sudden failure. Operations that reached the leader but had not yet been pulled by the follower are lost if the leader is destroyed at that instant.
• No cross-shard snapshot of a single moment. Queries that combine data from several shards see each shard at its own point.

Deletes and Updates

CCR copies everything that happens to a document, including updates and deletions. This is good for fidelity and bad for protection against mistakes. If an engineer accidentally deletes documents on the leader, the follower will mirror the deletion within moments. Keep this in mind whenever someone suggests that CCR “is our backup”.

The most common reason to use CCR is to survive the loss of an entire site. This chapter shows how a follower becomes the new primary system.

Two Numbers That Matter

Disaster planning uses two standard measures. The recovery point objective (RPO) is how much recent data you can afford to lose, measured in time. The recovery time objective (RTO) is how long you can afford to be without service. A business might say, “We can lose at most a minute of data and be down for at most thirty minutes.” CCR mainly helps with the RPO, by keeping the copy fresh, and helps with the RTO, by having the copy already loaded and ready.

The Failover Story

flowchart TD
    A["Normal: writes go to Leader cluster in Region A"] --> B["Region A fails"]
    B --> C["Decide to fail over"]
    C --> D["Pause following on Region B follower indices"]
    D --> E["Close each follower index"]
    E --> F["Unfollow to turn it into a normal index"]
    F --> G["Reopen the index in Region B"]
    G --> H["Redirect applications to Region B"]
    H --> I["Region B now accepts writes"]

Practice Makes the RTO

A disaster plan that has never been rehearsed is only a hope. Schedule a game day at least once or twice a year, in which you promote the followers, redirect a test application and measure how long each step takes. Write the steps in a short runbook, a plain checklist that someone half-awake at three in the morning can follow. Time the rehearsal, and use the real time as your RTO instead of a guess.

A second, nearby copy can make searches faster for users far from the main site, and can help meet rules about where data may live.

Distance Costs Time

Network signals travel fast, but not instantly, and long routes across oceans pass through many devices. A search that takes 20 milliseconds inside a data center can take several times longer when the user is on another continent, before we even count the time for the response to come back. Multiply that by the several requests a single web page might make, and the delay becomes something users feel.

By placing a follower cluster in each major region, searches from that region are answered close to home. Writes still go to the leader, and reads are served locally from the follower. Because most search applications read far more than they write, this sharply improves the everyday experience.

Rules About Location

Some regions require certain data to be stored or served inside their borders. A follower cluster in that region can hold a compliant local copy for serving users there. Whether a copy is allowed at all depends on the rules for your data and your industry. Speak with your legal and compliance teams before replicating personal or regulated data across borders, because the same feature that solves a speed problem can create a legal one.

Use the Right Node Sizes

Follower clusters serving reads need enough memory and processing power for search traffic, but they do not need to handle heavy indexing from applications, since the only writes they perform are the replicated operations. This can allow slightly different hardware choices from the leader, tuned to reading. Many teams also choose fewer replicas on the follower in regions with lower traffic, to save cost.

Sometimes the problem is the opposite of scattering data to many places. You have many small clusters and want everything in one.

Hub and Spoke

Imagine a retail chain with hundreds of stores, each running a small Elasticsearch cluster for local point-of-sale search and analysis. Head office wants to see sales across all stores without visiting each cluster one by one. With CCR, every store cluster acts as a leader for its own indices, and one large central cluster follows all of them. The central cluster becomes a complete, up-to-date reporting hub.

flowchart LR
    S1["Store cluster 1: leader"] --> H["Central reporting cluster: many follower indices"]
    S2["Store cluster 2: leader"] --> H
    S3["Store cluster 3: leader"] --> H
    S4["Store cluster N: leader"] --> H
    H --> D["Dashboards and analysts"]

A single follower cluster can follow indices from many leader clusters at once. Each follower index stands for one leader index, so you will have many follower indices in the hub, one per source index. Naming becomes important here. If every store names its sales index the same way, the hub needs a naming rule such as adding the store code as a prefix, so that names do not collide.

Why This Beats Visiting Each Cluster

Elasticsearch can also search many clusters at once through a different feature called cross-cluster search. That works well for occasional questions. For heavy, frequent reporting, having the data already in one place is faster, because the queries run locally in the hub without waiting for hundreds of remote clusters to answer. It also keeps reports working even if a store’s cluster is temporarily offline, since the hub already holds the latest copy.

Capacity for the Hub

The hub cluster must be able to store every followed index. Add up all the leader indices’ sizes, then the hub’s own replica shards, then room to grow. Many teams underestimate this and discover disk pressure after a few months. Combine storage planning with a retention plan, so that old data leaves the hub on a schedule.

So far, data flows one way for each index. Some organizations want both sites to accept writes. CCR can support this, but only with a careful design.

One Index Cannot Have Two Leaders

A follower index is read-only, and an index can only follow one leader. That means you cannot have two clusters both writing to the same index and copying to each other. If both sides could change the same document at the same time, there would be no rule to decide whose version wins, and the two copies would disagree.

The Prefix Pattern

The safe design gives each cluster its own writable index, and each cluster follows the other’s index. For example, the European cluster writes to an index whose name has a “eu” prefix. The American cluster writes to an index with a “us” prefix. Each cluster also holds a follower of the other’s index. A search that needs everything reads across both the local writable index and the follower index, usually through a shared alias or a wildcard.

Where This Works Well

This pattern suits data with a natural owner, such as logs generated by each region, orders placed in each region, or sensor data from local sites. Each record is created in exactly one place, so nothing needs merging. It is less suited to shared records that anyone might edit, such as a single global customer profile, because those need a different design.

Data does not live forever. Elasticsearch has a feature that moves indices through stages as they age, and it interacts with CCR in useful ways.

A Quick Look at Index Lifecycle Management

Index Lifecycle Management, or ILM, is a feature that automatically moves indices through stages: hot for fresh, busy data, then warm, cold and finally deletion as data ages. It can also start a new index when the current one gets too large, an action called rollover. ILM saves money and effort by keeping recent data on fast storage and pushing old data to cheaper storage.

Leader and Follower Have Their Own Lives

The leader and the follower each live in their own cluster, and each can have its own lifecycle policy. The leader’s policy might roll over daily and delete after thirty days. The follower’s policy could keep data longer, for example ninety days, if the follower cluster is used for reporting and has cheap storage available. Retention on the follower is your own choice.

Rollover is the special case. Only the leader can roll over, because a follower is read-only. The follower gets its new indices by following the leader’s new indices, either through an auto-follow pattern or a data stream. ILM has a specific step designed for follower indices, called unfollow, which detaches a follower from its leader once the leader has finished with it. This turns an old, finished index into an ordinary index that can be moved to colder storage or deleted in the normal way.

Elasticsearch offers several ways to reach across clusters or to protect data. Each solves a different problem, and confusing them is a common mistake.

Cross-Cluster Search in One Paragraph

Cross-cluster search leaves data where it is and travels to it. A search request goes to a local cluster, which forwards it to remote clusters, gathers their answers, and merges them into one result list. It is like phoning several offices to ask the same question. CCR, by contrast, copies the data so that the answer is already at hand. The two are often used together: CCR brings key indices close, and cross-cluster search reaches the rest.

Snapshots and CCR Are Partners

Snapshots and CCR protect against different dangers. CCR protects against the loss of a place, and it does so with small data loss and fast recovery. Snapshots protect against the loss of correctness, such as accidental deletion or corrupted data, because a snapshot can be taken before the mistake and restored afterward. A serious system uses both.

CCR adds work to both clusters and uses the network between them. Knowing where that work comes from lets you keep it under control.

Where the Work Happens

On the leader side, the extra work is answering read requests from followers and keeping the history of recent operations. On the follower side, the work is applying those operations as if they were normal writes, then copying them to follower replicas. Between them, the network carries every change. If your leader handles a heavy stream of writes, the follower must be able to absorb the same stream.

Why Latency Matters as Much as Bandwidth

Bandwidth is how much data the link can carry at once. Latency is how long a round trip takes. A follower that reads one small batch, waits for the answer and then asks again will be limited by latency, even on a very fast link. This is why followers can keep several requests in flight and read bigger batches. Think of moving water with buckets between two villages: a wide road helps, but so does sending many carriers at the same time so nobody stands waiting.

Scaling Out

CCR scales with the number of shards. More shards mean more follow tasks working in parallel, each pulling from its own leader shard. A very busy index with many shards can therefore replicate faster than a single-shard index that funnels all changes through one task. At the same time, too many tiny shards waste memory and add overhead, so keep shard sizes in a healthy range.

A follower index moves through clear stages from birth to retirement or promotion. Knowing these stages makes operations far less mysterious.

flowchart LR
    C["Created"] --> R["Remote recovery: bulk copy"]
    R --> F["Following: reading new operations"]
    F --> P["Paused"]
    P --> F
    F --> U["Unfollowed: becomes a normal index"]
    P --> U
    F --> X["Lagging or failing: needs attention"]
    X --> F
    X --> RB["Rebuilt from scratch"]
    RB --> C

The Data That Travels

The follower receives more than documents. When the leader’s mappings change, meaning the rules that describe the fields in the index, the follower picks up those changes as well, so both sides keep matching structures. Many index settings are also copied, so that the follower behaves like the leader. Settings that describe the follower’s own physical situation, such as the number of replica shards or where shards are placed, stay under the follower cluster’s control.

Concepts are easier to remember with a story. Here is a small made-up example that shows planning, lag and failover in numbers.

The Setting

An online marketplace runs its main Elasticsearch cluster in one region, which we will call Region A. It holds a product index of 400 gigabytes, and it receives about 800 changes per second on average, with peaks near 3,000 per second during sales. The business asks for a disaster recovery copy in Region B, with at most one minute of data loss and at most thirty minutes without service. All figures here are invented to illustrate the reasoning and are not from a real company.

Planning the Numbers

A Day in the Life

At first, the team creates one follower index for the product catalog and watches it for a week. Lag stays around two seconds. During a big sale, lag rises to 18 seconds for a few minutes, then falls back. The team sets an alert at 30 seconds and moves on.

Three months later, a power failure takes Region A offline at 14:05. Monitoring shows the leader unreachable at 14:06. At 14:10 the incident lead decides to fail over. The team follows the runbook: pause the follower indices, close them, unfollow, reopen, and change the gateway so that applications point to Region B. By 14:22 the site accepts orders again. The last recorded lag before the failure was 4 seconds, so at most about four seconds of changes were lost, well inside the one-minute goal.

When Region A returns hours later, the team does not try to reconnect its old indices. They delete the stale ones and create new followers in Region A that follow Region B. After they catch up, the business decides to keep Region B as the primary for now and use Region A as the new standby.

Two clusters joined by CCR share data over a network that may cross the public internet or a provider’s backbone. Security is not optional here.

Protect the Link

All traffic between clusters must be encrypted using TLS, the same technology that puts the padlock in a web browser. Encryption stops anyone on the path from reading or changing data in transit. Where possible, also keep the link off the public internet by using private connections, peering or virtual private networks, and limit network rules so that only the follower’s addresses can reach the leader’s cluster port.

Prove Who You Are

The follower cluster must show credentials to the leader. Depending on your version and setup, these can be certificates, or newer cross-cluster API keys that are limited to specific access on the leader. In both cases, treat the credentials like keys to a safe. Store them in a secrets manager, rotate them on a schedule, and remove them when a cluster is retired.

Give Only the Permissions Needed

Elasticsearch roles have special permissions for CCR. On the leader side, the credentials need only enough rights to read the leader index and its changes. On the follower side, the person or automation creating followers needs rights to manage follower indices and to write into them. The follower does not need any ability to change the leader, and it should not have one. This is the principle of least privilege: every person or program receives no more access than its job requires.

Data Follows the Rules

A follower holds a complete copy of the leader’s data, including sensitive fields. Any access control based on documents or fields in the leader does not automatically apply to the follower unless you define roles on the follower cluster too. Set up users, roles and audit logging on the follower with the same care as on the leader. Encrypt disks in both clusters, and remember that a second copy of sensitive data doubles the places where it must be protected.

CCR exists to help when things fail, and CCR itself can also fail. Plan for both.

What CCR Does When the Link Breaks

If the network between clusters drops, follow tasks cannot read from the leader. They do not give up at once. They retry with growing pauses between attempts, and they resume from their last checkpoint when the link returns. Since the leader keeps history under retention leases, a short outage is repaired automatically, with lag growing during the outage and shrinking after it.

Split-Brain Thinking for Two Sites

Suppose the link between regions breaks, but both regions are healthy. Each side may believe the other has failed. If your automation promotes the follower while the leader is still alive and receiving writes, you now have two writable copies that will drift apart. This is a split-brain situation. Guard against it by making failover a deliberate decision, confirming from an independent viewpoint that the leader is really down, and making sure old writers cannot keep writing after the switch.

A follower that silently stops following looks healthy until the day you need it. Good monitoring makes silent failures loud.

The Numbers That Matter

Where to Find Them

Elasticsearch offers statistics for individual follower indices and for the whole cluster, showing checkpoints, read and write counts, and recent exceptions. Kibana displays cross-cluster replication status in its management screens, and stack monitoring can collect metrics over time so you can chart them. Export the key numbers to the same dashboards and alerting tools that your team already uses, so CCR alerts arrive in the same place as every other alert.

Alerts That Help

• Lag above your RPO fraction. If the RPO is 60 seconds, alert at 30, so you can act before the goal is broken.
• Time since last read is climbing. This catches a stuck follower even when lag looks small because the leader is quiet.
• Any fatal error on a follow task. A fatal error means the follower has stopped and will not recover on its own.
• Missing followers. Compare the list of leader indices that match your patterns to the list of followers.
• Remote connection down. This gives the earliest warning of link or credential problems.

Logs and Audit Trails

Keep cluster logs for both sides, and record who created, paused, promoted or removed followers. During an incident review, these records answer questions like “who promoted the follower, and when?” Good records also help detect mistakes, such as a follower being paused for maintenance and forgotten for weeks.

CCR solves real problems, and it also brings real costs. A fair look at both sides helps you decide when it is worth using.

Key Trade-offs to Decide

Freshness versus cost. A faster link, more follower capacity and tighter monitoring keep lag lower, but each adds cost. Decide how fresh the copy must be and buy only that much.

Simplicity versus flexibility. One leader with one follower is easy to run and to explain. Hub-and-spoke and active-active patterns unlock more uses but need stronger discipline in naming, aliases and runbooks.

Speed of recovery versus risk of a wrong switch. Automated failover reduces the RTO, but it raises the risk of a mistaken failover or a split-brain. Manual failover is slower, but gives people a chance to confirm. Many teams choose semi-automated steps with a human decision at the start.

Local reads versus fresh reads. Serving users from a nearby follower gives speed, but with slightly old data. Serving everyone from the leader gives fresh data, but with more distance. Use each where it fits.

Teams that have run CCR in production repeat the same good habits, and the same avoidable mistakes.

Patterns That Work

Anti-Patterns to Avoid

A short list of habits that separate smooth CCR deployments from painful ones.

Common Mistakes

• Forgetting the license. Discovering late that the required subscription level is missing can stall an entire project.
• Underestimating storage. The follower holds a full copy plus its own replicas, and grows as the leader grows.
• Long pauses. Leaving a follower paused past the retention period forces a full rebuild.
• Name collisions. Copying similarly named indices from several leaders into one follower cluster without prefixes.
• Testing only the happy path. Trying CCR when everything is healthy, but never during a broken link or expired credential.
• Ignoring application changes. Failing to plan how applications will find the promoted cluster, for example through DNS or gateway settings.

Setting CCR up is one day of work. Running it for years is the rest. These are the routine tasks that keep a setup healthy.

Pausing and Resuming

Sometimes you need to stop following on purpose, for example during maintenance on the follower cluster or the network. Pausing a follower stops its read tasks but keeps its data. Resuming makes it continue from its last checkpoint. The important rule is to keep pauses short compared with the leader’s retention period. A pause of a few hours is usually harmless. A pause of several days may force a full rebuild.

Changing Mappings and Settings

When a new field is added on the leader, the follower learns about the new field automatically as part of following. You should not change the structure of a follower by hand while it is following, because the leader is the single source of truth. If you need a different structure, change it on the leader, or create a separate index on the follower side from the copied data.

Big structural changes, such as splitting an index into more shards, cannot be applied to a follower in place. The usual approach is to create a new leader index with the new layout, copy data into it and create a new follower for it. Plan these moves during quiet times, and keep the old pair running until the new pair is caught up and verified.

Rotating Credentials

Secrets should not live forever. When you rotate the credentials that the follower uses to reach the leader, update the remote cluster settings on the follower before the old credentials stop working. Check the connection afterward and confirm that lag stays low. Doing this on a schedule turns a risky emergency into a boring routine.

Upgrading

Cluster upgrades need special care because leader and follower must remain compatible with each other during the process. Read the upgrade notes for your versions, test in a copy of your setup, and upgrade in the order that Elastic’s documentation recommends. After each step, verify that following continues and that lag is normal. Keep the runbook for failover handy in case an upgrade goes wrong on one side.

Cleaning Up

Followers that nobody needs any more waste disk and network. Review the list of followers regularly. Remove those for retired indices, and unfollow those that are finished. Also review auto-follow patterns: an old pattern that still matches a busy naming scheme can fill the follower cluster with data that no longer has a purpose.

When something looks wrong, a calm, ordered check finds the cause faster than guessing. Work from the outside in.

Common Symptoms and First Guesses

Where the clusters run, and how they are connected, shapes cost, speed and risk.

Choosing Where Clusters Live

Clusters can run in your own data centers, on virtual machines in a public cloud, in containers managed by Kubernetes, or on a managed service such as Elastic Cloud. A common design places the leader in one cloud region or data center and the follower in another, far enough apart that one event cannot damage both. Choose locations with different power, network and natural risks, not just different rooms in the same building.

Connecting the Clusters

The network design has three choices. The clusters can talk over the public internet with strong encryption, over private links offered by the cloud or a telecom provider, or over a virtual private network. Private links give steadier speed and lower risk, but they cost more and take time to arrange. Whatever you choose, test the actual throughput and delay between the two sites before designing around them.

Counting the Cost

CCR costs money in four places. First, the follower cluster needs its own servers and disks. Second, the network link may have a fixed fee. Third, many cloud providers charge for data moved between regions, and a busy index can move a lot of data over a month. Fourth, people need time to build, test and maintain the setup. Estimate all four before deciding, and compare them with the cost of an outage for your business.

Environments and Releases

Practice in a test environment that mirrors production: two small clusters, the same security settings and realistic sample data. Use it to test upgrades, credential rotation and failover. Elasticsearch versions between leader and follower must be compatible, so read the compatibility rules in Elastic’s documentation before planning upgrades. Usually, you upgrade in an order that keeps the two clusters compatible at every step, rather than upgrading both at once.

The stories below are illustrative composites that show how organizations of different kinds use CCR. They are not accounts of specific companies.

Half-true ideas about CCR cause wasted effort and bad surprises. Here are the ones that appear most often.

A quick reference for the important words in this guide, in plain language.

Quick answers to the questions people ask most often when they first meet CCR.