需要一些关于运行 Cassandra 节点工具修复的说明

Question

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

我的问题是：

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

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

Answer 1

1) 如果我们丢失一个节点超过 3 小时，究竟会发生什么 提示/秒？它/它们不再存在了吗？

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

查看我们的docs 和Jonathan's blog post on HH。

2) 如果我们丢失一个节点超过 3 小时但由于某种原因 没想到节点宕机了那么久，会发生什么 如果运行 nodetool repair -pr 而不是完全修复 节点宕机了？

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

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

我建议您尝试使用自动执行此过程的OpsCenter repair service，而不是使用chron。

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

修复将使您回到完全一致的基线，这就是为什么您应该每周（或在

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

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

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