将“max_hint_window_in_ms”增加到天是个坏主意吗？答案

【问题标题】：Is increasing `max_hint_window_in_ms` to days a bad idea?将“max_hint_window_in_ms”增加到天是个坏主意吗？
【发布时间】：2017-07-09 20:22:01
【问题描述】：

我正在考虑将max_hint_window_in_ms 提高到 72 小时左右。有人看到这个问题吗？从本质上讲，这将使我们在一个周末的节点停机时间更长，而无需进行全面修复。

【问题讨论】：

假设您必须考虑您的写入/实时数据比率以及实时数据的绝对值，以决定是否在较长时间内累积提示然后进行处理是否比完整无论如何，建议在 gc_grace 之前对集群运行状况进行修复（默认 10 天）。

【解决方案1】：

这取决于版本。在C* 3.0 或 DSE 5.0 之后，暗示的切换存储被重构，实际上增加它是一个非常好的主意。在此之前（假设你是你的 2.1 标签）在this blog post 中突出显示了太多提示，存在很多问题。除非使用 3.0 之后的版本，否则不建议增加太多。

强调一些 3.0 之前的问题：

提示存储在 C* 表中，其行为类似于已知反模式的队列，会构建许多墓碑和缓慢/昂贵的读取
提示是按节点分区的，所以如果一个节点长时间停机，分区会变得非常大。这在最新的 C*/DSE 中得到了更好的处理，但特别是在 2.1 中，这会显着影响压缩和 gcs。
定期调用压缩并且是必需的，但如果没有删除任何内容，这意味着只需在节点关闭时一遍又一遍地重写突变（浪费）
单个突变需要通过 memtables 和完整的写入路径而不是仅附加到磁盘

【讨论】：