Read repair
When a read request involves multiple replicas, the coordinator node compares the data returned from each replica. If a replica’s response doesn’t match the other nodes, then the coordinator node triggers read repair to patch the mismatched replica.
The coordinator node uses records with the most recent timestamp for the read repair and the response to the read request.
Read repair limitations
|
Read repair isn’t the same as anti-entropy repair. Don’t rely on read repair as your sole means of synchronizing replicas. |
-
Read repair doesn’t propagate expired tombstones, and it doesn’t consider expired tombstones when selecting the most recent write for a given record. This can result in resurrected deletes (zombies) when repairing from replicas that contain missed deletes due to extended downtime. For more information, see Deletes and tombstones.
-
Read repair only includes the replicas selected for a read; all other replicas are excluded from the repair.
-
Read repair is never triggered at
ONEorLOCAL_ONEbecause those consistency levels read directly from one replica without comparing replicas. If replicas aren’t routinely repaired by other means, responses can be inconsistent when different nodes are selected for similar reads. -
Read repair runs in the foreground and blocks application operations, including responding to the original read request, until the repair is complete. If a cluster is stable and receives routine anti-entropy repairs and other consistency maintenance, read repairs shouldn’t occur frequently. If nodes frequently require read repair, there are underlying stability or consistency issues that need to be addressed.
