[
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
