cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3912) support incremental repair controlled by external agent
Date Sun, 15 Apr 2012 18:13:22 GMT


Stu Hood commented on CASSANDRA-3912:

bq. else if (range.intersects(toRepair))
The error message here could be a bit better: the solution is for the user to look at the
cluster layout, and use exact tokens, right? Also, it should be possible to repair a range
that falls on the boundary of two getLocalRanges, assuming it can be fully contained in their
aggregate: So it would be possible to merge all local ranges into one big range, which would
cause your {{if (range.contains(toRepair))}} check to succeed more frequently. Probably not
worth it for this patch though, unless Peter needs it for something.

bq. For JMX sakes
For JMX's sake.

bq. starting user-requested repair of range
Would including the 'future.session.getName' in this log message be useful, in order to link
the uuid of the repair to the message?


Looks like a good improvement to me. If Peter's happy, then +1 from me.
> support incremental repair controlled by external agent
> -------------------------------------------------------
>                 Key: CASSANDRA-3912
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Peter Schuller
>            Assignee: Peter Schuller
>             Fix For: 1.2
>         Attachments: 3912_v2.txt, CASSANDRA-3912-trunk-v1.txt, CASSANDRA-3912-v2-001-add-nodetool-commands.txt,
> As a poor man's pre-cursor to CASSANDRA-2699, exposing the ability to repair small parts
of a range is extremely useful because it allows (with external scripting logic) to slowly
repair a node's content over time. Other than avoiding the bulkyness of complete repairs,
it means that you can safely do repairs even if you absolutely cannot afford e.g. disk spaces
spikes (see CASSANDRA-2699 for what the issues are).
> Attaching a patch that exposes a "repairincremental" command to nodetool, where you specify
a step and the number of total steps. Incrementally performing a repair in 100 steps, for
example, would be done by:
> {code}
> nodetool repairincremental 0 100
> nodetool repairincremental 1 100
> ...
> nodetool repairincremental 99 100
> {code}
> An external script can be used to keep track of what has been repaired and when. This
should allow (1) allow incremental repair to happen now/soon, and (2) allow experimentation
and evaluation for an implementation of CASSANDRA-2699 which I still think is a good idea.
This patch does nothing to help the average deployment, but at least makes incremental repair
possible given sufficient effort spent on external scripting.
> The big "no-no" about the patch is that it is entirely specific to RandomPartitioner
and BigIntegerToken. If someone can suggest a way to implement this command generically using
the Range/Token abstractions, I'd be happy to hear suggestions.
> An alternative would be to provide a nodetool command that allows you to simply specify
the specific token ranges on the command line. It makes using it a bit more difficult, but
would mean that it works for any partitioner and token type.
> Unless someone can suggest a better way to do this, I think I'll provide a patch that
does this. I'm still leaning towards supporting the simple "step N out of M" form though.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message