在 cassandra 节点上定期进行 nodetool 修复的目的

Question

我正在学习文档和自学视频课程，请耐心等待。

建议在每个节点上频繁运行nodetool repair，具体原因不清楚。

当您进行写入时，协调器将请求发送到主令牌持有者节点，以及其他副本。假设所有节点都已启动，则所有节点应在短时间内同步。我假设删除和更新的工作方式与插入相同，只是添加了删除的墓碑标记。

因此，在没有节点宕机且网络延迟很小的完美情况下，运行nodetool repair 有什么优势？

在节点确实宕机的实际情况下，运行nodetool repair 允许宕机节点在切换提示过期的地方重新同步。

什么情况下数据可以复活？是否仅在节点停机时间超过 gc_grace_period 的情况下？还是这真的是一个网络延迟可能很大的问题？

另外，您如何有效地安排每个节点上的作业，以使它们不重叠？它必须随着集群大小的变化而动态调度，而且您可能不知道需要多长时间。

谢谢。

Answer 1

假设没有故障，运行修复是可选的。

• Cassandra wiki 指出，如果没有发生故障，您只需使用 HintedHandoff 即可。 https://wiki.apache.org/cassandra/Operations#Repairing_missing_or_inconsistent_data
• Datastax 也对此进行了扩展；如果您仅按 TTL 删除并具有同步时间，因此，我想，不必担心墓碑和 gc_grace_seconds + max_hint_window。 http://www.datastax.com/dev/blog/advanced-repair-techniques

话虽如此，Cassandra 的设计假设会发生某种故障；在商用硬件上运行时，总会出现问题。

在安排修复以避免“重叠”方面，我假设您的意思是在查询正在修复的范围时尽量减少性能下降：

• 使用顺序修复（每个副本依次修复）而不是并行（所有节点的 Merkle 树同时构建）。但是，需要权衡的是，顺序每次都会生成快照，并且不会尽快完成整个过程。
• 使用增量修复（尽管这会对您的压缩策略产生影响）
• 您还可以控制是否应在特定 DC 或集群范围内运行修复