如何防止Cassandra提交日志占用磁盘空间

Question

如何防止Cassandra提交日志占用磁盘空间

cassandradatastaxdatastax-java-drivercassandra-2.1

9

我在AWS上运行着一个两节点的Datastax AMI集群。昨天，Cassandra开始拒绝来自任何地方的连接，系统日志没有显示任何问题。经过大量调试后，我发现提交日志已经填满了分配的挂载点上的所有磁盘空间，这似乎导致连接被拒绝（删除一些提交日志，重新启动后就能连接了）。

我使用的是DataStax AMI 2.5.1和Cassandra 2.1.7。

如果我决定从头开始清除并重新启动所有内容，如何确保不再出现这种情况？

- plamb

2个回答

3

除了像BryceAtNetwork23建议的减少提交日志大小之外，确保不会再次发生的适当解决方案将监视磁盘设置，以便在其变满时警报并有时间采取行动/增加磁盘大小。

由于您正在使用DataStax，因此可以在OpsCenter中设置此警报。我自己没有在云中使用过这个功能，但我想它应该可以工作。可以通过点击顶部横幅中的“警报”->“管理警报”->“添加警报”来设置警报。配置要监视的挂载点和触发的阈值。

或者，我相信还有更好的工具来监视磁盘空间。

- Alec Collier

好主意！DataStax的人们总是说，一个大错误就是不使用（或者低效使用）OpsCenter。 - Aaron

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Aaron · Accepted Answer

您可以尝试降低在您的中的commitlog_total_space_in_mb设置。对于64位系统，默认设置为8192MB（在您的<.yaml>文件中应该是注释掉的...在设置它时，您需要取消注释）。通常，在规划磁盘大小时考虑这一点是个好主意。

您可以通过在提交日志目录上运行du来验证此操作：

$ du -d 1 -h ./commitlog
8.1G    ./commitlog

尽管较小的提交日志空间会导致更频繁的刷新（增加磁盘I/O），因此您需要关注一下。

编辑20190318

我对我的4年前的回答有一个相关的想法。我看到它最近受到了一些关注，并希望确保正确的信息出现。

重要的是要注意，有时提交日志可能会呈“失控”状态增长。基本上，这可能是因为节点上的写入负载超过了Cassandra跟上刷新memtable的能力（因此，删除旧的commitlog文件）。如果您发现一个节点有数十个commitlog文件，并且数量似乎不断增长，那么这可能是您的问题。

实际上，您的 memtable_cleanup_threshold 可能太低了。尽管该属性已弃用，但您仍然可以通过降低 memtable_flush_writers 的数量来控制它的计算。

memtable_cleanup_threshold = 1 / (memtable_flush_writers + 1)

文档已于3.x更新，但以前曾经这样说：

# memtable_flush_writers defaults to the smaller of (number of disks,
# number of cores), with a minimum of 2 and a maximum of 8.
# 
# If your data directories are backed by SSD, you should increase this
# to the number of cores.
#memtable_flush_writers: 8

......我感觉这导致很多人将这个值设置得太高。

假设设置为8，memtable_cleanup_threshold的值为.111。当所有memtable的占用空间超过可用内存的这个比例时，会进行刷盘操作。太多的刷盘操作会阻塞写入，从而使这一过程变得缓慢。对于只有一个/data目录的情况下，我建议将该值设置为2。