因此，我们在当前群集上平衡我们的工作负载时遇到了麻烦，主要原因是预算限制以及此时无法添加更多节点。直到最近，节点一夜之间发生频繁发生，所以我经常运行nodetool修复。最近集群变得更加稳定，这些被击落的节点并没有定期发生，所以上周末我为每个节点上的nodetool repair -pr创建了cron作业，每周运行一次。 gc_grace仍然默认为10天，最大提示仍然是默认值3小时。
我的问题是：
这还没有发生（至少我不这么认为），但是我试图提前计划最坏的情况因为我们的群集稳定性可能会或可能不会长期丢失所以我应尽可能做好准备。
答案 0 :(得分：2)
1）如果我们丢失节点的时间超过3小时，究竟会发生什么 提示/ s？它/它们不再存在吗？
是的，你的提示会被删除（逻辑删除），并且它们将通过常规的压缩过程消失。您实际上可以自己看到这一点，只需从system.hints表中选择。
查看我们的docs和Jonathan's blog post on HH。
2）如果我们丢失节点的时间超过3小时但由于某种原因 没有意识到节点已经长时间停机，会发生什么 如果运行nodetool repair -pr而不是完全修复 倒下的节点？
对于该节点重新启动和正在运行的修复之间的时间段，您可能正在保存过时数据。
-pr表示您只修复该计算机上的主要范围。如果您在整个群集中使用-pr运行修复，那么您仍然会修复所有内容。
我建议您尝试自动执行此过程的OpsCenter repair service，而不是使用chron。
3）如果事实如此，你如何解决问题2中的问题？ 案子？
修复会让你回到完全一致性的基线，这就是为什么你应该每周运行它（或者在＆lt; gc_grace中）。
4）有没有办法检查所有节点是否显着 一致/维修？
唯一的办法就是修建默克树，这就是维修。一旦发现不一致，您也可以修复。没有修复就没办法比较。
注意：3.0中有很好的提示改进，请查看Aleksey发布的这篇文章： http://www.datastax.com/dev/blog/whats-coming-to-cassandra-in-3-0-improved-hint-storage-and-delivery