[ https://issues.apache.org/jira/browse/CASSANDRA-14709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Steinmaurer updated CASSANDRA-14709: ------------------------------------------- Description: 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 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. 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 b) Our internal (support) tickets of course also state nodetool repair command without the -full option, as these 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 increment repair and allow full > repair only > ------------------------------------------------------------------------------------ > > Key: CASSANDRA-14709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14709 > Project: Cassandra > Issue Type: Bug > Reporter: Thomas Steinmaurer > Priority: Major > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x > > > 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 > 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org