[CASSANDRA-11696] Incremental repairs can mark too many ranges as repaired

• Type: Bug
• Status: Resolved
• Priority: Urgent
• Resolution: Fixed
• Fix Version/s: 2.1.15, 2.2.7, 3.0.8, 3.8
• Component/s: Legacy/Streaming and Messaging
• Severity: Critical
• Assignee: Marcus Eriksson
• Reporter: Joel Knighton

Authors

Marcus Eriksson

Reviewers

Joel Knighton

• Created: 02/May/16 16:03
• Updated: 16/Apr/19 09:30
• Resolved: 23/Jun/16 09:19

Description

Incremental repairs are tracked using a parent session - a subordinate repair session is created for each range in the repair. When a node participating in the repair receives a validation request, it will reference the sstables in the parent repair session. When all subordinate sessions conclude, each node anticompacts SSTables based on the parent repair session for the whole range of the repair, but these referenced SSTables may have only been present for the validation of some subset of the ranges because the SSTables were created concurrent with the parent repair session.

Issue Links

• is duplicated by: CASSANDRA-11906 Unstable JVM due too many files when anticompacting big LCS tables
• relates to: CASSANDRA-8366 Repair grows data on nodes, causes load to become unbalanced
• relates to: CASSANDRA-7586 Mark SSTables as repaired after full repairs