Cassandra 压缩 vs 修复 vs 清理答案

【问题标题】：Cassandra Compaction vs Repair vs CleanupCassandra 压缩 vs 修复 vs 清理
【发布时间】：2016-10-07 15:53:18
【问题描述】：

发了question，看了this和that的文章，还是不明白这三个操作的关系-

是否可以在压缩任务运行时处理修复任务，或者在压缩任务运行时进行清理？清理是需要每周执行的操作作为修复吗？为什么修复操作需要手动执行，而不是 Cassandra 默认行为？

健康集群维护的基本规则是什么？

【问题讨论】：

【解决方案1】：

cleanup 是一个压缩，它只是删除节点令牌范围之外的东西。 repair 有一个“Validation Compaction”来构建一个 merkle 树以与其他节点进行比较，因此 nodetool repair 的一部分将有一个压缩。

是否可以在压缩任务运行时处理修复任务，或者在压缩任务运行时进行清理？

有一个共享池用于跨正常压缩、修复、清理、清理等的压缩。这是 cassandra.yaml 中的 concurrent_compactors 设置，默认为核心数和数据目录的组合：@ 987654321@

清理是需要每周执行一次的操作吗？

不，只有在拓扑真正改变之后。

为什么修复操作需要手动执行，而不是 Cassandra 默认行为？

它的手册，因为它的要求可能与您的数据和gc_grace 要求有很大不同。 https://issues.apache.org/jira/browse/CASSANDRA-10070 将其带入 Cassandra，但未来它将是自动的。

健康集群维护的基本规则是什么？

我会（意见）说：

定期备份（取决于要求和可接受的数据丢失这可以是从每周/每天到不断增加的任何内容）。
- 这对于“内部”错误（“Opps 我删除了一个客户”）和中断一样多。即使是强大的多 DC 复制，您也需要一些最少的备份。
确保对所有在这些表的 gc_grace 时间内至少删除一次的表完成修复。
如果您希望能够调试问题，指标和日志存储非常重要。

【讨论】：