[
https://issues.apache.org/jira/browse/CASSANDRA-18528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722999#comment-17722999
]
Maciej Sokol commented on CASSANDRA-18528:
------------------------------------------
Partly, it explains that anticompaction is performed at the start instead of at
the end for incremental repairs. It doesn't explain why repairs with "-st,-et,
--in-dc" are considered incremental now.
Tbh, I don't mind them being incremental but I don't see any reason to do
anticompaction if we don't set the timestamp.
> Anticompaction triggered during repair when it's not needed
> -----------------------------------------------------------
>
> Key: CASSANDRA-18528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18528
> Project: Cassandra
> Issue Type: Bug
> Reporter: Maciej Sokol
> Priority: Normal
>
> I've been testing repair and different options and comparing Cassandra 4 to
> Cassandra 3.11.
> What i've discovered is some strange behavior in Cassandra 4, mainly when it
> comes to anticompaction. Anticompaction seems to be triggered when "–full" is
> not provided.
> I.e this will trigger anticompaction in Cassandra 4, but not in Cassandra
> 3.11:
> nodetool repair --in-dc datacenter1
> nodetool repair -st 5 -et 10
> The easiest way to observe this is to:
> * Disable autocompaction for a table
> * Run repair for a table
> * Observe the diskspace, every time a repair is triggered the diskspace
> increases by like 30% (not the case when used with --full)
> On top of that, even though anticompaction is triggered, the timestamp is not
> set on SSTables. It remains as 0. I don't really see any point in doing
> anticompaction, either we do anticompaction and set the timestamp or we don't
> do both.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
