[
https://issues.apache.org/jira/browse/CASSANDRA-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-3912:
----------------------------------------
Attachment: 3912_v2.txt
Attaching a new version (dubbed v2) of this. This changed the logic of
getNeighbors a bit so that:
# it returns no node if the provided range is not part of the local node
ownership. Currently, repair has been wrote with the assumption that the
repaired range was a local one. It could be that the code is able to cope with
the range not being a local one (I haven't checked) but I'd prefer avoiding the
risk of foot-shooting currently.
# it only allows range that are contained in a local range. Which excludes
ramge that overwrap 2 local ranges. I've explained the reason above: repair
will repair data that doesn't need to be otherwise.
Those are not really limiting anyway, since the correct way to use this is to
call repair on subsets of the primary range.
That patch also exposes forceTableRepairRange and getPrimaryRange (modified
from the preceding patch to return a list of String instead of a map entry just
because that's what other JMX function do) on JMX. The patch does not include
the nodetool counterpart. The vague reason is that since using this does
require some understanding of what's going on and to write some sufficiently
smart external tooling to work correctly, it feels like exposing through JMX
should be enough and exposing through nodetool may add more confusion than
benefits. I don't stand very strongly on that though so I could be convinced
otherwise if others feel differently.
I'll also note that I mentioned the flush problem for information/reminder
purposes only. I think fixing this one problem is beyond the scope of this
issue (which really just expose what already exists internally).
> 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
