Skip to main content

Reaper

Automated repairs can be scheduled with cassandra-reaper. It supports full and incremental repairs, controlled via a simple web-based UI.

Additional reaper settings are configurable from the reaper section in the config/samples/cassandracluster.yaml file.

Schedule Repairs​

The reaper object contains an optional scheduleRepairs field. This field defines reaper scheduled repairs. When the CassandraCluster CRD is initially deployed, a reaper client will schedule any repair tasks based on the configuration provided. The fields used to configure the repair intentionally match the Reaper APIs POST /repair_schedule method to avoid confusion. However, it is important to note there are possible configurations that are impossible for Reaper to support (so check the reaper container's logs). For example, repairParallelism must be parallel if incrementalRepair is true.

More information can be found through reaper's API and reaper specific documentation.

It's also important to consider whether you want to repair TWCS or DTCS tables. It is strongly advised not to repair these tables, so they are blacklisted by default. If you want to enable repairs on these types of tables, you can specify reaper.blacklistTWCS: false and REAPER_BLACKLIST_TWCS will be set accordingly.

See Reaper Repairs Configuration for a list of fields that can be configured. This is lifted directly from Reaper's API documentation with the options the chart doesn't support removed.

Here's an example of a weekly, datacenter aware repair on the counter1 table of keyspace1 that will use 2 threads:

  scheduleRepairs:
    enabled: true
    repairs:
    - keyspace: keyspace1
      tables: [counter1]
      scheduleDaysBetween: 7
      scheduleTriggerTime: "2020-09-08T04:00:00"
      datacenters: [dc1]
      repairThreadCount: 2
      intensity: "0.75"
      repairParallelism: "DATACENTER_AWARE"

Here's another example of a repair that occurs weekly but will repair all the tables in the keyspace and across all DCs.

    - keyspace: system_auth
      scheduleDaysBetween: 7
      scheduleTriggerTime: "2021-01-06T04:00:00"
      repairThreadCount: 4
      repairParallelism: "PARALLEL"

Monitoring​

Reaper metrics are reported by default via the Dropwizard Metrics interface. These metrics are accessible on reaper's admin port under the /prometheusMetrics route. If you would like Prometheus to scrape these metrics, you can enable the reaper service monitor by setting reaper.serviceMonitor.enabled to true. This will create a service monitor for reaper in the same namespace as your Cassandra cluster. You may also specify additional properties for the reaper service monitor, such as namespace, labels, and scrapeInterval. See the CassandraCluster field specification reference for more information on these fields.

Last updated on