[
https://issues.apache.org/jira/browse/CASSANDRA-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045336#comment-15045336
]
Jim Meyer commented on CASSANDRA-10070:
---------------------------------------
I don't know much about Cassandra internals, so one of the regular devs would
know better, buy my thought would be during a restart, somewhere it figures out
that it needs to replay part of the commit log to rebuild memtables that hadn't
been flushed to disk. The timestamp of the last thing in the commit log might
be a good estimate of when the node went down, and you could compare that to
the current time to figure out how long the node was down.
I wouldn't worry about the second case since it would be hard to get that right.
> Automatic repair scheduling
> ---------------------------
>
> Key: CASSANDRA-10070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10070
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Marcus Olsson
> Assignee: Marcus Olsson
> Priority: Minor
> Fix For: 3.x
>
>
> Scheduling and running repairs in a Cassandra cluster is most often a
> required task, but this can both be hard for new users and it also requires a
> bit of manual configuration. There are good tools out there that can be used
> to simplify things, but wouldn't this be a good feature to have inside of
> Cassandra? To automatically schedule and run repairs, so that when you start
> up your cluster it basically maintains itself in terms of normal
> anti-entropy, with the possibility for manual configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
