title: Clarifications about nodetool repair -pr
body: <p>From the <a href="http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_repair_nodes_c.html">documentation</a>:</p>
  
  <blockquote>
    <p>Using the nodetool repair -pr (–partitioner-range) option repairs only the primary range for that node, the other replicas for that range still have to perform the Merkle tree calculation, causing a validation compaction. Because all the replicas are compacting at the same time, <strong>all the nodes may be slow to respond for that portion of the data</strong>.</p>
  </blockquote>
  
  <p>There is probably never a time where I can accept all nodes to be slow for a certain portion of the data. But I wonder: Why does it do that <sup>(or is there maybe just a mixup with the "-par" option in the documentation?!)</sup>, when <code>nodetool repair</code> seems to be <a href="http://www.datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsRepair.html">smarter</a>:</p>
  
  <blockquote>
    <p>By default, the repair command takes a snapshot of each replica immediately and then sequentially repairs each replica from the snapshots. For example, if you have RF=3 and A, B and C represents three replicas, this command takes a snapshot of each replica immediately and then sequentially repairs each replica from the snapshots (A&lt;->B, A&lt;->C, B&lt;->C) instead of repairing A, B, and C all at once. This allows the dynamic snitch to maintain performance for your application via the other replicas, because <strong>at least one replica in the snapshot is not undergoing repair</strong>.</p>
  </blockquote>
  
  <p>However, the datastax blog <a href="http://www.datastax.com/dev/blog/advanced-repair-techniques">addresses this issue</a>:</p>
  
  <blockquote>
    <p>This first phase can be intensive on disk io, however. You can mitigate this to some degree with compaction throttling (since this phase is what we call a validation compaction.) Sometimes that isn’t enough though, and some people try to mitigate this further by using the -pr (–partitioner-range) option to nodetool repair, which repairs only the primary range for that node. Unfortunately, the other replicas for that range will still have to perform the Merkle tree calculation, causing a validation compaction. This can be a problem, since all the replicas will be doing it at the same time, possibly making them all slow to respond for that portion of your data. Fortunately, there is way around this by using the -snapshot option.</p>
  </blockquote>
  
  <p>That could be nice, but actually, there is no <code>-snapshot</code> option for <code>nodetool repair</code> (see the manpage, or the <a href="http://www.datastax.com/dev/blog/advanced-repair-techniques">documentation</a>) (has this option been removed?!)</p>
  
  <p>So overall, </p>
  
  <ul>
  <li>I cannot use <code>nodetool repair -pr</code>, it seems, because I always need at least to keep the system responsive enough to read/write with consistency ONE, without significant delay. (Note: We have only one data center.) Or am I missing/misunderstanding something?</li>
  <li>Why is <code>nodetool repair</code> smart, keeping one node responsive, while <code>nodetool repair -pr</code> makes all nodes slow for a portion of data?</li>
  <li>Where is the <code>-snapshot</code> option: Has it been removed, never implemented, or does it now maybe automatically work like that, also when using <code>nodetool repair -pr</code>?</li>
  </ul>