使用nodetool repair -pr（-partitioner-range）选项仅修复该节点的主要范围，该范围的其他副本仍然必须执行Merkle树计算，从而导致验证压缩。由于所有副本同时都是压缩的，所有节点可能对这部分数据的响应速度很慢。
可能从来没有一个时间我可以接受所有节点对于某一部分数据来说速度慢。但我想知道：为什么它会这样做（或者可能只是与文档中的＆＃34; -par＆＃34;选项混合起来？！），当nodetool repair似乎是smarter：
默认情况下，repair命令会立即获取每个副本的快照，然后从快照中依次修复每个副本。例如，如果您有RF = 3且A，B和C代表三个副本，则此命令立即获取每个副本的快照，然后从快照中顺序修复每个副本（A＆lt; B＆B; A＆lt; - ＆gt; C，B - C）而不是一次修复A，B和C.这允许动态snitch通过其他副本维护应用程序的性能，因为快照中至少有一个副本未进行修复。
但是，数据存档博客addresses this issue：
然而，第一阶段可以在磁盘上进行密集。您可以通过压缩限制在某种程度上缓解这种情况（因为这个阶段就是我们所说的验证压缩。）有时候这还不够，有些人试图通过使用-pr（-partitioner-range）来进一步缓解这种情况。 nodetool repair的选项，仅修复该节点的主要范围。不幸的是，该范围的其他副本仍然必须执行Merkle树计算，从而导致验证压缩。这可能是一个问题，因为所有副本都将同时执行此操作，可能使它们对于您的数据部分的响应速度都很慢。幸运的是，通过使用-snapshot选项可以解决这个问题。
这可能很好，但实际上，-snapshot没有nodetool repair选项（请参阅联机帮助页或documentation）（此选项已删除了吗？！）
总的来说，
nodetool repair -pr，因为我始终至少需要让系统保持足够的响应能力来读取/写入一致性ONE，而不会有明显的延迟。 （注意：我们只有一个数据中心。）或者我错过/误解了什么？nodetool repair智能，保持一个节点响应，而nodetool repair -pr使所有节点的数据部分变慢？-snapshot选项在哪里：是否已删除，从未实施，或现在可能会自动执行此操作，使用nodetool repair -pr时也是如此？答案 0 :(得分：5)
以下博客解决了这些问题：
http://www.datastax.com/dev/blog/repair-in-cassandra
简单的nodetool repair不仅会启动节点本身的修复，还会启动包含副本的所有节点（如果其范围）。虽然这没关系，但它非常昂贵，而且通常不是您在繁忙的生产系统中在高峰时段执行的操作。
因此nodetool repair -pr将对该节点上的主要范围进行修复。正如博客所说，您需要在群集的每个节点上运行此功能。拥有大型生产系统的客户通常会在其集群中以滚动方式使用它。
另一方面，Datastax OpsCenter提供了repair service，它一直运行较小的子范围修复，所以尽管你总是在较低的资源水平上一直在后台修复它。 / p>
对于快照，运行常规修复将按照您的说明调用快照，您也可以使用nodetool snapshot
希望这有帮助！