cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction
Date Wed, 20 Sep 2017 08:18:02 GMT


Stefan Podkowinski commented on CASSANDRA-13885:

If you really want to stop doing anti-compaction for full repairs, you'd also have to prevent
users from running both full and incremental repairs during their repair schedules. Or at
least make sure that incremental repairs - if run at all - will be run at least once before

What we need to avoid here is to end up with a tombstone in the repaired set and the corresponding
data in unrepaired. Assuming gc_grace has passed and both have already been compacted on the
other replicas, running incremental would zombie the data back to the replicas, as incremental
is only working on the unrepaired set, while the local tombstone is in the repaired set and
thus won't be transfered or considered during MT creation.

Really -1 on any changes to fundamental repair assumptions and paradigms in 3.0, if not for
really critical bug fixing

> Allow to run full repairs in 3.0 without additional cost of anti-compaction
> ---------------------------------------------------------------------------
>                 Key: CASSANDRA-13885
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Thomas Steinmaurer
> This ticket is basically the result of the discussion in Cassandra user list:
> I was asked to open a ticket by Paulo Motta to think about back-porting running full
repairs without the additional cost of anti-compaction.
> Basically there is no way in 3.0 to run full repairs from several nodes concurrently
without troubles caused by (overlapping?) anti-compactions. Coming from 2.1 this is a major
change from an operational POV, basically breaking any e.g. cron job based solution kicking
off -pr based repairs on several nodes concurrently.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message