[
https://issues.apache.org/jira/browse/CASSANDRA-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254391#comment-13254391
]
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: https://issues.apache.org/jira/browse/CASSANDRA-3912
> 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,
> CASSANDRA-3912-v2-002-fix-antientropyservice.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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
