【发布时间】：2014-11-18 17:30:04
【问题描述】：
使用 nodetool repair -pr (--partitioner-range) 选项仅修复该节点的主要范围，该范围的其他副本仍然必须执行 Merkle 树计算，从而导致验证压缩。因为所有副本都在同时压缩，所有节点可能对这部分数据的响应速度很慢。
可能永远不会有任何时候我可以接受所有节点对数据的某个部分变慢。但我想知道：为什么会这样做（或者可能只是与文档中的“-par”选项混淆？！），而nodetool repair 似乎是smarter:
默认情况下，repair 命令会立即对每个副本进行快照，然后从快照中依次修复每个副本。例如，如果你有 RF=3 并且 A、B 和 C 代表三个副本，则此命令立即对每个副本进行快照，然后从快照中顺序修复每个副本（AB，AC， BC) 而不是一次性修复 A、B 和 C。这允许动态告密者通过其他副本来维持您的应用程序的性能，因为快照中至少有一个副本没有进行修复。
不过，datastax 博客addresses this issue：
但是，第一阶段可能会占用大量磁盘 io。您可以通过压缩限制在一定程度上缓解这种情况（因为这个阶段就是我们所说的验证压缩。）有时这还不够，有些人试图通过使用 -pr (-partitioner-range) 来进一步缓解这种情况nodetool repair 的选项，它只修复该节点的主要范围。不幸的是，该范围的其他副本仍然必须执行 Merkle 树计算，从而导致验证压缩。这可能是一个问题，因为所有副本将同时执行此操作，这可能会使它们都响应您的那部分数据的速度变慢。幸运的是，使用 -snapshot 选项可以解决这个问题。
这可能很好，但实际上，nodetool repair 没有 -snapshot 选项（请参阅手册页或 documentation）（此选项是否已删除？！）
总的来说，
- 似乎我不能使用
nodetool repair -pr，因为我总是需要至少保持系统足够的响应以一致地读/写ONE，而没有明显的延迟。 （注意：我们只有一个数据中心。）还是我遗漏/误解了什么？ - 为什么
nodetool repair聪明，让一个节点保持响应，而nodetool repair -pr让所有节点对部分数据变慢？ -
-snapshot选项在哪里：它是否已被删除、从未实现，或者它现在是否可以自动像这样工作，在使用nodetool repair -pr时也是如此？
【问题讨论】：
-
似乎可以安全地假设在撰写博客时（2013 年 7 月）有一个快照选项，因为 Cassandra 1.2 文档讨论了一个节点工具修复-快照选项：datastax.com/documentation/cassandra/1.2/cassandra/operations/…。
-
此文档包含一些 nodetool 使用信息（不推荐使用 -pr 选项）并包含使用并行 (par) 选项的示例。 datastax.com/documentation/cassandra/2.1/cassandra/tools/…
-
@catpaws：谢谢，您的两个 cmets 都包含一些非常有价值的信息（实际上不在 2.0 文档中）！
-
我认为
-snapshot选项在 2.0 中已成为默认行为，而添加了-par选项以允许访问以前的行为（如果您可以接受对性能和/或希望修复更快完成。 -
@catpaws - 奇怪的是，从您引用的文档链接的 this doc 说 -pr 选项是建议用于日常维护。