Skip to content
AxonOps Documentation

AxonOps — AI-Native Control Plane for Open Source Data Platforms

Read Repair

During read operations that contact multiple replicas, the coordinator may receive different versions of the same data. When divergence is detected, the coordinator determines the authoritative version by timestamp and propagates it to replicas holding stale data. This process is called read repair.

Read repair is opportunistic: it operates only on partitions that are actually read, at the consistency level used for that read.

How It Works

Section titled “How It Works”
QUORUM read discovers inconsistency:


Client reads user_id=123 with QUORUM (2 of 3 replicas):


N1: user_id=123 → name='Alice',  timestamp=1000
N2: user_id=123 → name='Alicia', timestamp=2000  ← Newer


Coordinator:
1. Compares timestamps across all replica responses
2. Returns 'Alicia' (newer) to client immediately
3. Sends async repair mutation to N1: "update to 'Alicia' at ts=2000"


After repair:
N1: user_id=123 → name='Alicia', timestamp=2000  ← Fixed
N2: user_id=123 → name='Alicia', timestamp=2000

The coordinator always returns the most recent value to the client. The repair propagation to stale replicas is asynchronous — it does not add latency to the read response.

Background Reconciliation (Cassandra 4.0+)

Section titled “Background Reconciliation (Cassandra 4.0+)”

In Cassandra 4.0+, read repair uses background reconciliation exclusively. The result is returned to the client immediately; stale replicas are updated asynchronously after the response is sent.

Prior to 4.0, a blocking mode (read_repair = 'BLOCKING') was available, which held the response until all contacted replicas acknowledged the repair write. This mode was removed in 4.0.

Configuration

Section titled “Configuration”

Read repair is attempted automatically when divergence is detected during a read that contacts multiple replicas. The only configuration available in Cassandra 4.0+ is per-table opt-out:

-- Disable read repair for a specific table
ALTER TABLE my_table WITH read_repair = 'NONE';

Removed in Cassandra 4.0

The following table properties and behaviors were removed in 4.0:

  • read_repair_chance — was a per-read probability (0.0–1.0) for triggering speculative repair even without detected divergence
  • dclocal_read_repair_chance — same, scoped to the local datacenter
  • read_repair = 'BLOCKING' — synchronous repair mode; background is now the only mode

Limitations

Section titled “Limitations”
LimitationImplication
Query-drivenOnly partitions that are read undergo repair
Single partition scopeDoes not propagate corrections across partition boundaries
Requires multiple replica contactCL=ONE reads contact only one replica; no comparison is possible
Does not cover cold dataPartitions never read after divergence remain inconsistent indefinitely

Cold data — partitions written but rarely or never queried — requires scheduled anti-entropy repair to achieve convergence. Read repair alone is insufficient for full cluster consistency.

Best Practices

Section titled “Best Practices”
PracticeRationale
Use QUORUM or higher for important readsEnables divergence detection across replicas
Monitor reconciliation rateSustained high rate indicates systemic replica lag
Do not depend solely on read repairCold data requires scheduled repair to converge
Section titled “Related Documentation”