Analyses / Replica convergence

Replica repair: what has actually converged?

13 October 2026 · Documentation review · Cassandra 5.0.0

Reachable replicas are not necessarily synchronized replicas. The useful question is which data, on which replicas, a completed repair actually covered.

Three mechanisms, different coverage

A documentation comparison, not a measured repair benchmark.

Mechanism	What it reaches	What remains unproved
Hinted handoff	Retained missed mutations	Completeness of historical data [2]
Read repair	Queried data and participating replicas	Unread data and other replicas [1]
Anti-entropy repair	Selected shared ranges	Coverage outside completed scope [3]

Cassandra hints are best effort. Draining a queue proves neither that every missed update had a hint nor that unrelated inconsistencies were repaired. [2] Its max_hint_window limits generation during an endpoint's unavailability; it is not a universal hint lifetime or a deadline for convergence. [6]

Reconciliation is not always a repair write

When read repair is triggered, Cassandra 5.0.0's default BLOCKING setting waits for enough repair acknowledgements to meet the consistency level. NONE still reconciles responses but does not write repairs. [1]

BLOCKING supports monotonic quorum reads. However, a narrow SELECT can repair only part of a broader partition write, breaking partition-level write atomicity. NONE avoids that repair-induced effect but does not provide monotonic quorum reads. Neither setting is a general transaction guarantee. [1]

A small counterexample you can reproduce

Consider two rows, x and y, in one partition. An unsuccessful quorum write leaves A at (1,1) and B/C at (0,0). In our constructed model, reading x from A/B with blocking repair makes B=(1,0). A subsequent x/y read from B/C then returns (1,0). With response-only reconciliation, the second read instead returns (0,0).

The three state traces, CSV and executable model expose the assumptions and include a both-rows control. This illustrates the documented tradeoff [1]; it is not a Cassandra execution or a frequency estimate.

A completed job needs a coverage record

Cassandra compares shared token ranges with Merkle trees and transfers differences. Full repair revisits all data in the selected range; incremental repair excludes data already marked repaired, so later corruption can escape that pass. A single node's repair is not a whole-cluster audit. [3]

A preview is not a repair: --preview estimates streaming, while--validate compares already-repaired data. Neither streams corrections. A successful diagnostic must not be recorded as completed data repair. [3]

Hesela's operational inference: retain the software version, keyspaces, tables, ranges, participants, repair mode, exclusions, completion state and failures. Check the completed coverage, not merely the time a scheduler started a job.

Deletion markers make missed coverage consequential

A replica that misses a deletion can retain an older value. If other replicas later purge the tombstone, that value can spread again. Expiry of gc_grace_seconds only permits removal; compaction and overlapping-data conditions still matter. [4]

Our inference: evaluate completed repair coverage and outage history against the configured deletion-protection window. A running job or a healthy status screen does not establish that every relevant replica received the marker.

Agreement does not choose the correct history

Dynamo's 2007 design uses temporary hinted replicas and per-range trees to reduce divergence. It separately handles causal version reconciliation and application resolution of concurrent versions. Its opportunistic read repair can follow the client response, unlike Cassandra's blocking mode. This is historical Dynamo, not a claim about today's DynamoDB. [5]

Hesela's synthesis: convergence, authority and durability are separate questions. Hashes locate disagreement; they do not decide application intent. Agreement cannot recreate information absent from every surviving copy.

Continue with replication acknowledgement stages, consistency and ordering, hash and identity limits and local deletion persistence.

Sources and limitations

This is a primary-source synthesis. No Cassandra cluster was run, no data was repaired and no repair latency or loss probability was measured. Implementation statements are pinned to the Apache Cassandra 5.0.0 source tag, not generalized to later releases. The comparison and operational checklist are editorial interpretations.

Sources reviewed 13 October 2026.