[
https://issues.apache.org/jira/browse/CASSANDRA-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239291#comment-13239291
]
Sylvain Lebresne commented on CASSANDRA-3912:
---------------------------------------------
bq. What if we dropped our philosophy that client timestamps aren't necessarily
timestamps? I can't think of anyone actually using non-clock-based timestamps.
Then we could usefully compare server time to data timestamps and create a tree
of "data inserted before repair beginning."
That wouldn't fully solves it because in-memtable resolution is lossy. In other
words, even if timestamps are clock-based, you cannot get correct snapshot of
in-memory data which is what we would need.
> 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: 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
