May*_*tel 9 maintenance cassandra
我对 Cassandra 缺乏经验，但我对基于 SQL 的关系数据库有一些经验。
我一直无法找到有关如何在部署后维护 Cassandra 的最佳实践信息。是否有必要对数据库进行 VACUUM？我应该认为读/写负载会导致存储碎片。
或者更一般地说：维护 Cassandra 生产部署的最佳实践是什么？必须定期执行哪些操作才能保持系统的健康？操作手册确实没有讨论这个方面。
谢谢。
小智 14
一般来说，一个设计良好的集群可以在不被触碰的情况下存活数年。我有运行多年的集群。但是，这里有一些指导原则：
监控非常重要：
1) 监控延迟。使用 opscenter 或您最喜欢的指标工具来跟踪延迟。延迟上升可能是问题出现的迹象，包括 GC 暂停（在读取工作负载中比在写入工作负载中更常见）、sstable 问题等。
2) 监控 sstable 计数。如果您超限压缩，SSTable 的计数会增加（每个 sstable 只写入一次 - 通过压缩将旧的 sstable 合并为新的 sstable 来处理删除）。
3) 监控节点状态变化（up/down等）。如果您看到节点摆动，请进行调查，因为这不正常。
4) 跟踪您的磁盘使用情况 - 传统上，您需要保持在 50% 以下（特别是如果您使用 STCS 压缩）。
有一些基本的事情你应该和不应该经常做：
1) 不要显式运行nodetool compact. 你提到你已经做到了，这不是致命的，但它确实创建了非常大的 sstables，然后它们不太可能参与向前推进的压缩。您不一定需要继续运行它，但有时它可能有助于摆脱已删除/覆盖的数据。
2)nodetool repair通常建议每一次gc_grace_seconds（默认为 10 天）。在某些工作负载中，这不太重要 - 您需要修复的最大原因是确保删除标记 ( tombstones) 在它们到期之前传输（它们存在于gc_grace_seconds，如果在删除发生时节点关闭，该数据可能会恢复生机没有维修！）。如果您不发出删除命令，并且以足够的一致性级别进行查询（例如，在 QUORUM 上读取和写入），您实际上可以过上无需修复的生活。
3）如果要修复，考虑使用增量修复，一次修复小范围。
4）压实策略很重要 - 很多。STCS 非常适合写入，LCS 非常适合读取。DTCS 有一些怪癖。
5) 数据模型很重要——就像 RDBMS/SQL 环境在未索引的查询遇到大表时遇到问题一样，Cassandra 在处理非常大的行/分区时可能会出现问题。
6) 快照很便宜。非常便宜。几乎是即时的，只是硬链接，它们几乎不会立即占用磁盘空间。在升级版本之前使用快照，尤其是主要版本。
7) 小心删除。正如#2 中所暗示的， delete 在磁盘上创建更多数据，并且不会为 AT LEAST 释放它gc_grace_seconds。
当所有其他方法都失败时：
我看过一些文章表明 Cassandra in prod 需要一个专门的负责人来管理任何规模的集群——我不知道这是否一定是真的，但如果你担心，你可能想聘请第三方顾问（TheLastPickle、Pythian ) 或签订支持合同 (Datastax)，让您高枕无忧。