2

因此，我们一直无法平衡当前集群上的工作负载，主要是由于预算限制和目前无法添加更多节点。直到最近，一个节点在一夜之间宕机的情况经常发生，所以我经常运行 nodetool repair。最近集群变得更加稳定，这些宕机的节点不会经常发生，所以上周末我为每个节点上的 nodetool repair -pr 创建了 cron 作业，每周运行一次。gc_grace 仍为默认 10 天，最大提示仍为默认 3 小时。

我的问题是：

  1. 如果我们丢失一个节点超过 3 个小时，提示/秒到底会发生什么？它/它们不再存在吗？
  2. 如果我们丢失了一个节点超过 3 个小时，但由于某种原因没有意识到该节点已经停机那么久，如果运行 nodetool repair -pr 而不是对停机节点进行完全修复会发生什么？
  3. 如果确实如此，您将如何解决问题 2 中的问题？
  4. 有没有办法检查所有节点是否显着一致/修复？

这还没有发生（至少我不这么认为），但我正在努力为最坏的情况提前计划，因为我们的集群稳定性可能会或可能不会长期失去，所以我宁愿做好准备能够。

4

1 回答 1

2

1）如果我们失去一个节点超过 3 小时，提示/秒到底会发生什么？它/它们不再存在吗？

是的，没错，您的提示将被删除（墓碑化），并且它们将通过常规压缩过程消失。您实际上可以自己看到这一点，只需从system.hints表中选择即可。

查看我们的文档和Jonathan 在 HH 上的博客文章。

2) 如果我们丢失一个节点超过 3 个小时，但由于某种原因没有意识到该节点已经停机那么久，如果运行 nodetool repair -pr 而不是对停机节点进行完全修复会发生什么?

在该节点重新启动和您正在运行修复之间的时间段内，您可能正在保存陈旧的数据。

-pr意味着您只需修复该机器上的主要范围。如果您在整个集群中使用 -pr 运行修复，您仍将修复所有内容。

我建议您尝试使用OpsCenter 修复服务，而不是使用 chron，它可以自动执行此过程。

3) 如果确实如此，您将如何解决问题 2 中的问题？

修复将使您回到完全一致性的基线，这就是为什么您应该每周运行它（或在 < gc_grace 中）。

4) 有没有办法检查所有节点是否显着一致/修复？

唯一的方法是构建默克尔树，这就是修复所做的。一旦发现不一致，您不妨修复。没有办法只比较而不修理。

注意：3.0 中的提示改进很好，请查看 Aleksey 的这篇文章： http ://www.datastax.com/dev/blog/whats-coming-to-cassandra-in-3-0-improved-hint-storage-and -送货

于 2015-02-25T21:19:41.147 回答