[
https://issues.apache.org/jira/browse/CASSANDRA-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209117#comment-13209117
]
Peter Schuller edited comment on CASSANDRA-3912 at 2/16/12 5:22 AM:
--------------------------------------------------------------------
Agreed.
The good news is that the actual commands necessary ({{getprimaryrange}} and
{{repairrange}}) are easy patches.
The bad news is that it turns out the AntiEntropyService does not support
arbitrary ranges.
Attaching {{CASSANDRA\-3912\-v2\-001\-add\-nodetool\-commands.txt}} and
{{CASSANDRA\-3912\-v2\-002\-fix\-antientropyservice.txt}}.
Had it not been for AES I'd want to propose we commit this to 1.1 since it
would be additive only, but given the AES fix I don't know... I guess probably
not?
It's a shame because I think it would be a boon to users with large nodes
struggling with repair (despite the fact that, as you point out, each repair
implies a flush).
was (Author: scode):
Agreed.
The good news is that the actual commands necessary ({{getprimaryrange}} and
{{repairrange}}) are easy patches.
The bad news is that it turns out the AntiEntropyService does not support
arbitrary ranges.
Attaching {{CASSANDRA\-3912\-v2\-001\-add\-nodetool\-commands.txt}} and
{{CASSANDRA-3912-v2-002-fix-antientropyservice.txt}}.
Had it not been for AES I'd want to propose we commit this to 1.1 since it
would be additive only, but given the AES fix I don't know... I guess probably
not?
It's a shame because I think it would be a boon to users with large nodes
struggling with repair (despite the fact that, as you point out, each repair
implies a flush).
> 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
> Attachments: 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
