Thomas Steinmaurer created CASSANDRA-14709:
----------------------------------------------
Summary: 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
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 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
