定期nodetool repair在我的 Cassandra 节点上运行会削弱它们吗？
Planet Cassandra 常见问题解答说明（重点添加）
反熵节点修复——对于不经常读取的数据，或更新已宕机时间较长的节点上的数据，节点修复过程（也称为反熵修复）确保一个节点上的所有数据副本是一致的。节点修复（使用 nodetool 实用程序）应作为常规集群维护操作的一部分定期运行。
这是我见过的唯一nodetool repair定期运行的参考。如果它便宜，定期运行它不会有问题，但它到底有多贵？它是否相当于对节点上的每条记录进行一致性检查读取？还是比这更聪明？文档提到了 Merkle 树的使用，但这并没有让我知道操作的成本有多大。
如果您在一个节点上有 500 GB 的数据，并且该节点实际上与其他节点一致（修复是无操作的），那么修复从磁盘读取多少数据（读取所有 500 GB 需要几个小时）？以及通过 LAN 发送多少数据（通过 LAN 发送全部 500 GB 可能需要另一个小时左右）。
一些用例比其他用例更依赖于定期维修。如果您在低于 ConsistencyLevel.ALL 的情况下执行删除，那么您应该运行修复以确保已删除的列不会恢复生机。如果您不执行删除操作，则在许多情况下，您可以依靠提示切换和读取修复来保持一致性。如果您以低一致性级别读写，或者经常出现服务器停机或过载，您可能需要运行修复。
修复所做的是读取运行它的节点上的所有数据（可选，使用 -pr（主范围）选项，仅该节点拥有主范围的范围）并构建 Merkle 树。它还向存储任何这些范围的副本的所有节点发送一条消息以执行相同的操作 - 它们只会读取在初始修复节点上复制的数据。
在一个 500 GB 的节点上构建 Merkle 树将读取完整的 500 GB（使用 -pr 时，它大致会降低复制因子的一个因子）。但是，Merkle 树的大小是恒定的（几 MB），因此如果节点同步，则通过网络发送的内容很少。
运行计划修复的最佳方式是依次在每个节点上使用 -pr 运行。这避免了多次修复相同的数据。此外，一次只能在一个节点上运行，以避免给集群带来额外的负载。