所以我做了一些测试运行/灾难恢复实践，删除表并通过我构建的测试集群上的快照在 Cassandra 中恢复。
这个测试集群有四个节点，我使用了节点重启方法，所以在截断有问题的表后，所有节点都被关闭，commitlog 目录被清除，并且当前快照数据被复制回每个节点的表目录中。之后，我恢复了每个节点。然后按照文档，我对每个节点进行了修复，然后在每个节点上进行了刷新。
我的问题是，为什么我必须在之后假设没有节点关闭，除非我关闭它们以执行恢复过程时对每个节点运行修复？ （在这个测试实例中，它是少量数据并且需要很短的时间来修复，如果在我们的生产环境中发生这种情况，修复将需要大约 12 小时才能执行，所以这对我们来说在灾难场景中可能是一个巨大的问题） .
我认为在单个节点实例上运行修复是完全没有必要的，对吗？
只是想弄清楚运行修复和后续刷新的目的是什么。
【问题讨论】：
标签： cassandra cassandra-2.0 datastax datastax-enterprise
修复是 Cassandra 的主要反熵机制之一。从本质上讲，它确保您的所有节点都拥有所有数据的最新版本。需要 12 小时（顺便说一下，这很正常）的原因是它是一项昂贵的操作——io 和 CPU 密集型——为所有数据生成 merkel 树，将它们与来自其他节点的 merkel 树进行比较，并流式传输任何数据缺少/过时的数据。
修复为您提供了一个一致性基线。例如：如果快照不是在完全相同的时间拍摄的，如果您使用 CL ONE 并点击从旧快照恢复的副本，您就有机会读取过时的数据。修复可确保您的所有副本都是最新的可用最新数据。
维修大约需要 12 小时才能完成，所以这可能是一个巨大的 在灾难情况下对我们来说是个问题）。
在您进行修复时，如果您的快照没有完全相同的数据，您将面临读取过时数据的风险。如果它们是旧快照，gc_grace 可能已经通过了某些 tombstone，如果 tombstone 没有在您的集群中很好地传播，则给您带来更高的僵尸数据风险。
维修一词的通俗定义似乎暗示您的系统已损坏。我们认为“我必须进行维修？我一定是做错了什么才能达到这种未修复状态！”这是不正确的。修复是 Cassandra 的正常维护操作。实际上，您应该至少每隔 gc_grace 秒运行一次修复，以确保数据一致性并避免僵尸数据（或使用opscenter repair service）。
在我看来，我们应该将其命名为 AntiEntropyMaintenence 或 CassandraOilChange 或其他名称，而不是 Repair :)
【讨论】：