[CASSANDRA-7168] Add repair aware consistency levels

• Type: Improvement
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 5.x
• Component/s: Legacy/Coordination
• Labels: performance repair
• Assignee: Unassigned
• Reporter: T Jake Luciani
• Created: 06/May/14 01:10
• Updated: 08/Nov/23 22:56

Description

With CASSANDRA-5351 and CASSANDRA-2424 I think there is an opportunity to avoid a lot of extra disk I/O when running queries with higher consistency levels.

Since repaired data is by definition consistent and we know which sstables are repaired, we can optimize the read path by having a REPAIRED_QUORUM which breaks reads into two phases:

1) Read from one replica the result from the repaired sstables.
2) Read from a quorum only the un-repaired data.

For the node performing 1) we can pipeline the call so it's a single hop.

In the long run (assuming data is repaired regularly) we will end up with much closer to CL.ONE performance while maintaining consistency.

Some things to figure out:

• If repairs fail on some nodes we can have a situation where we don't have a consistent repaired state across the replicas.

Issue Links

• is blocked by: CASSANDRA-5839 Save repair data to system table
• relates to: CASSANDRA-19007 Queries with multi-column replica-side filtering can miss rows
• relates to: CASSANDRA-4914 Aggregation functions in CQL
• relates to: CASSANDRA-5791 A nodetool command to validate all sstables in a node
• requires: CASSANDRA-9111 SSTables originated from the same incremental repair session have different repairedAt timestamps