我正在通过文档和自定进度的视频课程，所以请耐心等待。
建议在每个节点上频繁运行nodetool repair，这是不清楚的原因。
当您进行写入时，协调器会将请求发送到主令牌持有者节点，也会发送到其他副本。假设所有节点都已启动，则所有节点应在短时间内保持同步。我假设删除和更新都以与插入相同的方式工作，并添加了用于删除的逻辑删除标记。
因此，在一个完美的情况下，没有任何节点出现故障且网络延迟很小，运行nodetool repair的优势是什么？
在节点确实关闭的现实情况下，运行nodetool repair允许已关闭的节点重新同步切换提示已到期的位置。
在什么情况下数据可以复活？是仅在节点停机时间长于gc_grace_period的地方？或者这真的是网络延迟可能很大的问题吗？
另外，如何有效地安排每个节点上的作业，使它们不重叠？它必须在群集大小发生变化时进行动态调度，也可能不知道它需要多长时间。
谢谢。
答案 0 :(得分：2)
假设没有失败，运行维修是可选的。
话虽如此，Cassandra的设计假设会发生某种失败;当在商用硬件上运行时，某些东西总会破碎。
在调度修复以避免“重叠”方面，我假设您的意思是在查询正在修复的范围时尝试最小化性能下降：