[
https://issues.apache.org/jira/browse/CASSANDRA-14709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Steinmaurer updated CASSANDRA-14709:
-------------------------------------------
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.
was:
We are running Cassandra in AWS and On-Premise at customer sites, currently 2.1
in production with 3.0/3.11 in pre-production stages including loadtest.
In a migration path from 2.1 to 3.11.x, I’m afraid that at some point in time
we end up in incremental repairs being enabled / ran a first time
unintentionally, cause:
a) A lot of online resources / examples do not use the _-full_ command-line
option available since 2.2 (?)
b) Our internal (support) tickets of course also state nodetool repair command
without the -full option, as these examples are for 2.1
Especially for On-Premise customers (with less control than with our AWS
deployments), this asks a bit for getting out-of-control once we have 3.11 out
and nodetool repair being run without the -full command-line option.
With troubles incremental repair are introducing and incremental being the
default since 2.2 (?), what do you think about a JVM system property,
cassandra.yaml setting or whatever … to basically let the cluster administrator
chose if incremental repairs are allowed or not? I know, such a flag still can
be flipped then (by the customer), but as a first safety stage possibly
sufficient enough.
> Global configuration parameter to reject repairs with anti-compaction
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-14709
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14709
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair, Local/Config
> Reporter: Thomas Steinmaurer
> Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
