9

从文档中：

使用 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，因为我总是需要至少保持系统足够响应以保持一致的 ONE 读/写，而不会出现明显延迟。（注意：我们只有一个数据中心。）还是我遗漏/误解了什么？
  • 为什么nodetool repair聪明，让一个节点保持响应，同时nodetool repair -pr让所有节点对一部分数据变慢？
  • 选项在哪里-snapshot：它是否已被删除，从未实现，或者它现在是否可以自动像这样工作，也在使用时nodetool repair -pr？
4

1 回答 1

5

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

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

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

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

另一方面，Datastax OpsCenter 提供维修服务，该服务始终运行较小的子范围维修，因此尽管您始终在后台以较低的资源级别对其进行修复。

至于快照，运行常规修复将调用您所说的快照，您也可以使用自己调用快照nodetool snapshot

希望这可以帮助！

于 2015-01-17T20:36:00.243 回答