cassandra - 如何防止 Cassandra 提交日志填满磁盘空间

Question

我正在 AWS 上运行一个两节点 Datastax AMI 集群。昨天， Cassandra 开始拒绝一切事物的连接。系统日志没有显示任何内容。经过大量修改后，我发现提交日志已填满分配的挂载上的所有磁盘空间，这似乎导致连接拒绝(删除了一些提交日志，重新启动并重新启动)能够连接)。

我使用的是 DataStax AMI 2.5.1 和 Cassandra 2.1.7

如果我决定删除并从头开始重新启动所有内容，如何确保这种情况不会再次发生？

Answer 1

您可以尝试降低 cassandra.yaml 中的 commitlog_total_space_in_mb 设置。 64 位系统的默认值为 8192MB(应在您的 .yaml 文件中将其注释掉...设置时必须取消注释)。在调整磁盘大小时对此进行规划通常是个好主意。

您可以通过在提交日志目录上运行 du 来验证这一点:

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

尽管如此，较小的提交日志空间会导致更频繁的刷新(增加磁盘 I/O)，因此您需要密切关注这一点。

编辑20190318

刚刚有一个相关的想法(关于我 4 年前的答案)。我看到它最近受到了一些关注，并想确保那里有正确的信息。

值得注意的是，有时提交日志可能会以“失控”的方式增长。从本质上讲，发生这种情况是因为节点上的写入负载超出了 Cassandra 跟上刷新内存表(从而删除旧提交日志文件)的能力。如果您发现一个节点有数十个提交日志文件，并且数量似乎在不断增长，那么这可能是您的问题。

本质上，您的 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。当所有内存表的占用量超过可用总内存的比率时，就会发生刷新。太多的刷新(阻塞)写入器可以方便地防止这种情况发生。对于单个 /data 目录，我建议将此值设置为 2。