所以我做了一些测试运行/灾难恢复练习，删除了一个表，并通过我构建的测试集群上的快照在Cassandra中进行恢复。
此测试集群有四个节点，我使用了节点重启方法，因此在截断相关表后，所有节点都被关闭，commitlog目录被清除，当前快照数据被复制回每个节点的表目录。之后，我重新启动了每个节点。然后按照文档我在每个节点上运行修复，然后在每个节点上刷新。
我的问题是，为什么我必须在每个节点上运行修复，假设没有任何节点关闭，除非我关闭它们以执行恢复过程？ （在这个测试实例中，它只是少量数据，并且只需要很少的时间进行修复，如果在我们的生产环境中发生这种情况，维修将花费大约12个小时来执行，因此这对于我们在灾难情况下可能是一个巨大的问题）
我认为在单个节点实例上运行修复是完全没有必要的，对吗？
试图找出运行修复和后续刷新的目的是什么。
答案 0 :(得分：1)
修复是Cassandra的主要反熵机制之一。从本质上讲，它确保所有节点都具有所有数据的最新版本。之所以需要12个小时（顺便说一下这是正常的）是因为为所有数据生成merkel树是一项昂贵的操作（io和CPU密集型），将它们与来自其他节点的merkel树进行比较，然后流式传输丢失/过时的数据。
修复为您提供一致性基线。例如：如果快照没有在同一时间拍摄，如果您正在使用CL ONE并点击从旧快照恢复的副本，则您有可能读取过时数据。修复可确保您的所有副本都是最新的，并提供最新数据。
维修需要大约12个小时才能完成，所以这可能是一个巨大的问题 灾难情景中的问题。）
在修复运行期间，如果您的快照没有相同的确切数据，您将有一些阅读过时数据的风险。如果它们是旧快照，gc_grace可能已经通过了一些墓碑，如果墓碑没有在整个集群中传播，那么僵尸数据的风险会更高。
术语修复的通俗定义似乎暗示您的系统已损坏。我们认为＆＃34;我必须进行维修？我必须做错了才能进入未修复的状态！＆＃34;这是不正确的。维修是Cassandra的正常维护操作。实际上，您应该至少每隔gc_grace秒运行一次修复，以确保数据一致性并避免使用僵尸数据（或使用opscenter repair service）。
在我看来，我们应该将其称为AntiEntropyMaintenence或CassandraOilChange或其他而不是Repair：）