只想了解“nodetool repair＆＃39;在使用Cassandra 2的多数据中心设置中。
我们计划在每个数据中心拥有2-4个副本的密钥空间。我们可能有几十个数据中心。根据情况，使用LOCAL_QUORUM / EACH_QUORUM一致性完成写入，并且读取通常使用LOCAL_QUORUM一致性完成。问题：
nodetool修复复杂性是否会随着所有数据中心的副本数量呈线性增长？
或者，nodetool修复复杂度是否与当前数据中心的副本数量和数据中心数量的组合线性增长？模糊地说，这个模型可能会与当前数据中心的每个单独节点同步数据，但是在与其他数据中心的副本进行类似EACH_QUORUM的操作时。
要扩展群集，最好是在现有数据中心中添加更多节点，还是在假设整个副本数量恒定的情况下添加新数据中心？我在nodetool修复性能的上下文中提出了这个问题。
答案 0 :(得分：8)
要了解nodetool修复如何影响群集或群集大小如何影响修复，我们需要了解修复期间发生的情况。修复有两个阶段，第一阶段是构建数据的Merkle树。第二个是让副本实际比较它们的树之间的差异，然后根据需要将它们相互流式传输。
第一阶段可以在磁盘上进行密集，因为它将触及运行修复的节点上磁盘上的几乎所有数据。避免修复触摸整个磁盘的一种简单方法是使用-pr标志。使用-pr时，它将磁盘化/ RF而不是修复必须触摸的磁盘大小数据。在节点上运行修复还会向存储任何这些范围的副本的所有节点发送消息，以构建merkle树。这可能是一个问题，因为所有副本都将同时执行此操作，可能使它们对于您的数据部分的响应速度都很慢。
决定修复操作如何影响其他数据中心的因素是使用副本放置策略。由于您需要跨数据中心保持一致性（EACH_QOURUM案例），因此必须在您的案例中使用跨网络复制策略，如网络拓扑策略。对于修复，这意味着您在运行修复时不能将自己限制为本地DC，因为您有一些EACH_QUORUM一致性情况。为了避免修复影响所有数据中心中的所有副本，您应该a）使用Dynamic snitch包装复制策略并正确配置不良阈值b）运行修复时使用-snapshot选项。 这样做的是拍摄数据的快照（快照只是现有sstables的硬链接，利用sstables不可变的事实，从而使快照非常便宜）并从快照中顺序修复。这意味着对于任何给定的副本集，一次只有一个副本将执行验证压缩，允许动态snitch通过其他副本维护应用程序的性能。
现在我们可以回答你的问题了。
nodetool修复复杂性是否会随着所有数据中心的副本数量呈线性增长？ 您可以通过在修复期间使用Dynamic snitch和pass -snapshot选项包装复制策略来限制此操作。
或者，nodetool修复复杂度是否与当前数据中心的副本数量和数据中心数量的组合线性增长？模糊地说，该模型可能与当前数据中心中的每个单独节点同步数据，但是对于其他数据中心中的副本，类似于EACH_QUORUM操作。 如果使用上述方法，复杂性的运行时间将增加复杂性。这是因为上述方法将一次对一个副本进行顺序修复。
要扩展群集，最好是在现有数据中心中添加更多节点，还是在假设整个副本数量恒定的情况下添加新数据中心？我在nodetool修复性能的上下文中提出这个问题。 从nodetool修复角度来看，如果你采用上述方法，这没有任何区别。因为它取决于副本的总数。
此外，使用nodetool进行修复的目的是删除不会返回。常规修复频率的硬性要求是gc_grace_seconds的值。在很少删除或覆盖数据的系统中，您可以提高gc_grace的值，同时对磁盘空间的影响最小。这允许使用nodetool实用程序调度修复操作的更宽间隔。避免频繁修复的推荐方法之一是通过设计使记录不变。这可能对您很重要，因为您需要在数十个数据中心上运行，否则操作将会很痛苦。