Read Repair: repair during read path

Describes read repair, repair during read path.

When a read query encounters inconsistent results at a consistency level greater than ONE or LOCAL_ONE, DSE initiates a read repair. Such read repairs run in the foreground and block application operations until the repair process is complete.
Note: Read queries with a consistency level of ONE or LOCAL_ONE do not block application operations since a data mismatch must exist to trigger the read repair, and, since only one replicas is queried, no comparison occurs, therefore no mismatch.
In more detail:
  1. The coordinator node asks one replica for data and the others for a digest of their data.
  2. If there is a mismatch in the data returned to the coordinator from the replicas, a read is requested from all replicas involved in the query (dictated by the consistency level) and the results are merged.
  3. If a single replica doesn't have all of the latest data for each column, a new record is assembled by mixing and matching columns from different replicas.
  4. After determining the latest version, the record is written back to only the replicas involved in the request.
For example, in the case of a LOCAL_QUORUM read with a replication factor of three, two replicas are queried, so only those two replicas are repaired.
Note: Read repair does not propagate expired tombstones, nor does it consider expired tombstones when actually repairing data. That means that if there is tombstoned data that has not been propagated to all replica nodes before gc_grace_seconds has expired, that data may continue to be returned as live data.

Read repair cannot be performed on tables that use DateTieredCompactionStrategy (DTCS) - Deprecated, due to the method of checking timestamps used in DTCS compaction.