关于nodetool repair -pr的澄清

Question

从文档:

使用nodetool repair -pr(-partitioner-range)选项仅修复该节点的主要范围,该范围的其他副本仍然必须执行Merkle树计算,从而导致验证压缩.因为所有副本同时是压缩的,所以所有节点对于该部分数据的响应可能很慢.

可能从来没有一个时间我可以接受所有节点对于某一部分数据来说速度慢.但我想知道:为什么会这样做^{(或者可能只是在文档中使用"-par"选项混合？!)},当时nodetool repair看起来更聪明:

默认情况下,repair命令会立即获取每个副本的快照,然后从快照中按顺序修复每个副本.例如,如果您有RF = 3且A,B和C代表三个副本,则此命令立即获取每个副本的快照,然后从快照中顺序修复每个副本(A < - > B,A < - > C, B - - C)而不是一次修复A,B和C. 这允许动态snitch通过其他副本维护应用程序的性能,因为快照中至少有一个副本没有进行修复.

但是,datastax博客解决了这个问题:

然而,第一阶段可能在磁盘上密集.您可以通过压缩限制在某种程度上缓解这种情况(因为这个阶段就是我们所说的验证压缩.)有时候这还不够,有些人试图通过使用-pr(-partitioner-range)来进一步缓解这种情况. nodetool repair的选项,仅修复该节点的主要范围.不幸的是,该范围的其他副本仍然必须执行Merkle树计算,从而导致验证压缩.这可能是一个问题,因为所有副本都将同时执行此操作,可能使它们对于您的数据部分的响应速度都很慢.幸运的是,通过使用-snapshot选项可以解决这个问题.

这可能很好,但实际上,没有-snapshot选项nodetool repair(参见联机帮助页或文档)(已删除此选项？!)

总的来说,

• 我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 repair不仅会启动节点本身的修复,还会启动包含副本的所有节点(如果其范围).虽然这没关系,但它非常昂贵,而且通常不是您在繁忙的生产系统中在高峰时段执行的操作.

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

另一方面,Datastax OpsCenter提供维修服务,该服务一直运行较小的子范围维修,所以尽管你总是在较低的资源水平上一直在后台修复它.

对于快照,运行常规修复将按照您的说明调用快照,您也可以使用自己调用快照 nodetool snapshot

希望这可以帮助!