cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13885) Allow to run full repairs in 3.0 without additional cost of anti-compaction
Date Wed, 20 Sep 2017 09:19:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16172945#comment-16172945
] 

Paulo Motta commented on CASSANDRA-13885:
-----------------------------------------

bq. What we need to avoid here is to end up with a tombstone in the repaired set and the corresponding
data in unrepaired.

Given that anti-compaction is non-deterministic on 3.0 due to CASSANDRA-9143, you can't guarantee
both the data and the tombstone will be marked as repaired after incremental repair so this
will be always a potential problem whether or not you run anti-compaction after full-repairs.
I don't see how running anti-compaction after full repairs can improve this since it's still
subject to the same limitations. Since I might be missing some edge case here, would you mind
giving an example where skipping anti-compaction after full repair could be a problem when
mixing with incremental repairs?

bq. Or at least make sure that incremental repairs - if run at all - will be run at least
once before gc_grace.

This is a basic requirement of repair, so if you don't do that you're basically accepting
the risk of data resurrection - whether or nor anti-compaction is run after full repairs.

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

I'd agree with that if we had reliable incremental repairs which is not the case on 3.0, and
we were just fully conscious about its limitations quite late on 3.0 line, but some users
are just starting to adopt 3.0, so it's fair to give them an option to stick with non-incremental
repairs if they prefer so for operational reasons. Perhaps we could just add a {{\-\-skip-anticompaction}}
flag which can be used together with {{--full}} to skip anti-compactions?

> Allow to run full repairs in 3.0 without additional cost of anti-compaction
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13885
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13885
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Thomas Steinmaurer
>
> This ticket is basically the result of the discussion in Cassandra user list: https://www.mail-archive.com/user@cassandra.apache.org/msg53562.html
> 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
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message