我在 AWS 上运行一个两节点 Datastax AMI 集群。昨天，Cassandra 开始拒绝一切连接。系统日志什么也没显示。经过大量修改后，我发现提交日志已经填满了分配的挂载上的所有磁盘空间，这似乎导致了连接拒绝（删除了一些提交日志，重新启动并能够连接）。
我正在使用 DataStax AMI 2.5.1 和 Cassandra 2.1.7
如果我决定从头开始擦除并重新启动所有内容，我如何确保不会再次发生这种情况？
问问题
14068 次
2 回答
10
commitlog_total_space_in_mb您可以尝试降低cassandra.yaml. 对于 64 位系统，默认值为 8192MB（它应该在您的文件中被注释掉.yaml……您必须在设置时取消注释它）。在调整磁盘大小时计划好通常是个好主意。
du您可以通过在您的 commitlog 目录上运行 a 来验证这一点：
$ du -d 1 -h ./commitlog
8.1G ./commitlog
虽然，较小的提交日志空间会导致更频繁的刷新（增加磁盘 I/O），因此您需要密切关注这一点。
编辑 20190318
刚刚有一个相关的想法（关于我 4 岁的答案）。我看到它最近受到了一些关注，并想确保那里有正确的信息。
需要注意的是，有时提交日志会以“失控”的方式增长。本质上，这可能是因为节点上的写入负载超出了 Cassandra 跟上刷新 memtables 的能力（因此，删除了旧的 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。
于 2015-07-30T21:33:02.843 回答
2
除了按照 BryceAtNetwork23 的建议减少提交日志的大小之外，确保不会再次发生的适当解决方案将监视磁盘设置，以便在磁盘已满时收到警报并有时间采取行动/增加磁盘大小。
看到您正在使用 DataStax，您可以在 OpsCenter 中为此设置警报。我自己没有在云中使用过它，但我想它会起作用。可以通过单击顶部横幅中的警报 -> 管理警报 -> 添加警报来设置警报。配置要监视的挂载和要触发的阈值。
或者，我确信有更好的工具来监控磁盘空间。
于 2015-07-31T06:43:32.470 回答