[CASSANDRA-14709] Global configuration parameter to reject repairs with anti-compaction

• Type: Improvement
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 3.0.x, 3.11.x
• Component/s: Consistency/Repair, Local/Config
• Labels: gsoc2021 mentor
• Complexity: Normal
• Assignee: Unassigned
• Reporter: Thomas Steinmaurer

Reviewers

Paulo Motta

• Created: 09/Sep/18 08:36
• Updated: 09/Mar/21 12:22

Description

We have moved from Cassandra 2.1 to 3.0 and from an operational aspect, the Cassandra repair area changed significantly / got more complex. Beside incremental repairs not working reliably, also full repairs (-full command-line option) are running into anti-compaction code paths, splitting repaired / non-repaired data into separate SSTables, even with full repairs.

Casandra 4.x (with repair enhancements) is quite away for us (for production usage), thus we want to avoid anti-compactions with Cassandra 3.x at any cost. Especially for our on-premise installations at our customer sites, with less control over on how e.g. nodetool is used, we simply want to have a configuration parameter in e.g. cassandra.yaml, which we could use to reject any repair invocations that results in anti-compaction being active.

I know, such a flag still can be flipped then (by the customer), but as a first safety stage possibly sufficient enough to reject anti-compaction repairs, e.g. if someone executes nodetool repair ... the wrong way (accidentally).

Issue Links

• relates to: CASSANDRA-11511 disable Anticompaction after repair