C. Scott Andreas updated CASSANDRA-14709:
    Component/s: Repair

> 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: Wish
>          Components: Configuration, Repair
>            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 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.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to