[ 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