在我的 Cassandra 节点上定期运行 nodetool repair 会削弱它们吗？
Planet Cassandra FAQ 指出(强调)
这是我见过的唯一一个定期运行 nodetool repair 的引用。如果它便宜，定期运行它不会成为问题，但它到底有多贵？它是否相当于对节点上的每条记录进行一致性检查读取？或者比这更聪明？文档提到了 Merkle 树的使用，但这并没有让我知道操作的成本有多高。
如果您在一个节点上有 500 GB 的数据，并且该节点实际上与其他节点一致(修复是空操作)，那么修复从磁盘读取了多少数据(读取所有 500 GB 将需要几个小时)？以及通过 LAN 发送多少数据(通过 LAN 发送所有 500 GB 可能需要一个小时左右)。
最佳答案
一些用例比其他用例更依赖于定期维修。如果您以低于 ConsistencyLevel.ALL 的速度执行删除，那么您应该运行修复以确保已删除的列不会恢复生机。如果不做删除，很多情况下可以依靠hinted handoff和read repair来保持一致性。如果您以低一致性级别进行读写，或者经常出现服务器停机或过载，您可能需要运行修复。
修复的作用是读取运行它的节点上的所有数据(可选地，使用 -pr(主要范围)选项，仅读取节点拥有主要范围的范围)并构建 Merkle 树。它还向所有存储这些范围中任何一个的副本的节点发送一条消息，以执行相同的操作——它们将只读取在初始修复节点上复制的数据。
在具有 500 GB 的节点上构建 Merkle 树将读取完整的 500 GB(使用 -pr 时，它将大致降低复制因子的一个因素)。但是，Merkle 树的大小是恒定的(几 MB)，因此如果节点同步，则通过网络发送的数据很少。
运行预定修复的最佳方法是在每个节点上依次使用 -pr 运行。这避免了多次修复相同的数据。此外，一次只能在一个节点上运行，以避免给集群带来额外的负载。
关于cassandra - "nodetool repair"操作的成本有多高？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/17617344/