cassandra - 关于nodetool Repair -pr 的说明

Question

来自documentation :

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, all the nodes may be slow to respond for that portion of the data.

我可能永远不会接受所有节点对于数据的某一部分都变慢的情况。但我想知道:为什么它会这样做^{(或者可能只是与文档中的“-par”选项混合？!)}，当nodetool Repair似乎是smarter :

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<->B, A<->C, B<->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 at least one replica in the snapshot is not undergoing repair.

但是，datastax 博客 addresses this issue :

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.

这可能很好，但实际上，没有用于 nodetool Repair 的 -snapshot 选项(请参阅联机帮助页，或 documentation )(此选项是否已删除了？!)

总的来说，

• 我似乎无法使用nodetool Repair -pr，因为我总是需要至少保持系统足够的响应能力，以一致性 ONE 进行读/写，而不会出现明显的延迟。 (注意:我们只有一个数据中心。)还是我遗漏/误解了什么？
• 为什么 nodetool Repair 很智能，可以保持一个节点响应，而 nodetool Repair -pr 却会使所有节点在处理部分数据时变慢？
• -snapshot 选项在哪里:它是否已被删除、从未实现，或者现在是否在使用 nodetool Repair -pr 时自动像这样工作？

Answer 1

下面的博客解决了这些问题:

http://www.datastax.com/dev/blog/repair-in-cassandra

简单的nodetool修复不仅会启动节点本身的修复，还会启动保存副本(如果其范围)的所有节点。虽然这没问题，但它非常昂贵，并且通常不会在高峰时段在繁忙的生产系统上执行该操作。

因此，nodetool Repair -pr 将对该节点上的主要范围进行修复。正如博客所述，您需要在集群的每个节点上运行它。拥有大型生产系统的客户通常会在其集群中以滚动方式使用它。

另一方面，Datastax OpsCenter 提供 repair service它始终运行较小的子范围修复，因此尽管您始终以较低的资源级别在后台修复它。

对于快照，运行定期修复将调用快照，如您所述，您也可以使用 nodetool snapshot 自己调用快照

希望这有帮助!