CODEWITHSUNDEEP
cassandra
Mohan Narayanaswamy
Mohan Narayanaswamy

Reputation: 2149

When Apache Cassandra scheduled repair becomes necessary operational practice?

Like eventual consistency, scheduled repair seems eventually useful from nodes drifting away too much from other. Trying to understand why and when "Scheduled Repair" becomes mandatory. We are relatively new to operating Cassandra and progressively adopting it. Despite there are no scheduled repairs configured, few services are working quite well for months. Hence, Have few questions about repair?

  1. What is the statistical evidence that developer reliably look at, so he/she can understand the immediate or eventual benefit of repair processes?
  2. Is there any indicator (from log or metrics) that warns ahead of time about need of repair?
  3. If we build read-heavy (very rare transaction) reference data system, do we still need to repair regularly?
  4. Mistakenly if material-views used in application, should we abstain repair till we re-write applications without material-views?

Upvotes: 2

Views: 60

Answers (1)

Erick Ramirez
Erick Ramirez

Reputation: 16293

The answer is simple -- repair is part of the normal operation of Cassandra.

There are no metrics/statistics/indicators that determine when to run repairs. You just have to run repairs once every gc_grace_seconds. It's as simple as that.

By default, GC grace is 10 days so for simplicity you should run repairs at least once a week if you're not using automated tools like Reaper -- the free, open-source tool for automated Cassandra repairs. Cheers!

Upvotes: 4

Related Questions