根据文件：
使用nodetool repair-pr（–partitioner range）选项仅修复该节点的主范围，该范围的其他副本仍需执行merkle树计算，从而导致验证压缩。因为所有的复制副本都是同时压缩的，所以所有节点对这部分数据的响应可能都很慢。
可能从来没有一次我可以接受所有节点对于某一部分数据都很慢。但我想知道：为什么它会这样做（或者只是在文档中混用了“-par”选项？！），什么时候 nodetool repair 似乎更聪明：
默认情况下，repair命令立即获取每个复制副本的快照，然后从快照中依次修复每个复制副本。例如，如果rf=3且a、b和c表示三个副本，则此命令会立即获取每个副本的快照，然后依次从快照（a<->b、a<->c、b<->c）修复每个副本，而不是同时修复a、b和c。这允许动态告密者通过其他副本来维护应用程序的性能，因为快照中至少有一个副本没有进行修复。
然而，datastax博客解决了这个问题：
但是，第一阶段在磁盘io上可能非常密集。您可以通过压缩限制在某种程度上缓解这种情况（因为这个阶段就是我们所说的验证压缩阶段）。但有时这还不够，有些人试图通过使用-pr（–partitioner range）选项来进一步缓解这种情况，nodetool repair只修复该节点的主范围。不幸的是，该范围内的其他副本仍然必须执行merkle树计算，从而导致验证压缩。这可能是一个问题，因为所有复制副本都将同时执行此操作，可能会使它们对该部分数据的响应速度变慢。幸运的是，通过使用-snapshot选项可以解决这个问题。
那可能很好，但事实上，没有 -snapshot 的选项 nodetool repair （请参阅手册页或文档）（是否已删除此选项？！）
所以总的来说，
我不能用 nodetool repair -pr ，似乎是因为我总是需要至少让系统保持足够的响应性，以便以一致性1进行读/写，而不会有明显的延迟(注意：我们只有一个数据中心。）还是我遗漏了什么？
为什么是 nodetool repair 智能，保持一个节点响应，同时 nodetool repair -pr 使所有节点的一部分数据变慢？
火车在哪里 -snapshot 选项：它是否已经被删除，从未实现过，或者它现在是否会自动像那样工作，在使用时也是如此 nodetool repair -pr ?