为什么在 cassandra 中清理 nodetool 后丢失了一些数据答案

【问题标题】：why lost some data after nodetool cleanup in cassandra为什么在 cassandra 中清理 nodetool 后丢失了一些数据
【发布时间】：2017-06-11 21:02:44
【问题描述】：

我们向数据中心添加了一个新节点，然后根据Add new node to existing cluster in cassandra运行nodetool cleanup。但是在清理完成后，我们注意到我们丢失了一些数据。

可能是什么原因？

【问题讨论】：

【解决方案1】：

nodetool cleanup 释放不再属于节点的分区键，因此在添加节点并传输它的部分数据后，该“部分”不再属于旧节点，因此运行清理将在此释放一些空间节点。

如果您看到旧节点现在存储空间较低，那没关系，没有任何数据丢失。

另一方面，如果您确实找不到某些数据，则可能是由于数据损坏或已删除数据（带有墓碑）。无论如何，数据丢失是什么意思？

【讨论】：

【解决方案2】：

是的，重要的是要了解nodetool cleanup 是一种潜在的破坏性工具。您的集群需要处于完全修复的状态（之前定期成功运行 nodetool repair）。

当您将新节点添加到集群时，每个节点负责的令牌范围会进行调整，并按节点降低。这会将数据留在他们不再负责的原始节点上。这是设计。

这个想法是，如果由于某种原因节点添加过程失败并且您不得不将集群保留为原始大小，那么数据仍然存在。但是，如果您不能保证您的集群一开始就处于完全修复状态并且运行了清理，则可能并非所有副本都能到达其正确的节点。但就像nodetool getendpoints 一样，引导过程会假设它是。

这就是为什么确保在运行nodetool cleanup之前在集群上定期运行nodetool repair很重要。

【讨论】：

我同意nodetool repair 应该定期运行，正如您正确指出的那样，这非常重要。但是nodetool cleanup 只会清除节点不拥有的范围。因此，如果说一旦您启动了就无法真正修复，因为现有节点上的这些范围已被有效地否认，这不是更准确吗？
@markc 只要一个副本存活并使其进入节点上的有效范围，修复（引导后）应该会有所帮助。这样，错过的副本应该被流式传输。但是，如果某个范围的所有副本都已损坏或不在拥有的范围内，那么您在引导后的修复中确实不会做太多事情。