我正在AWS上运行双节点Datastax AMI群集。昨天，卡桑德拉开始拒绝一切的联系。系统日志没有显示。经过 lot 修补后，我发现提交日志已经填满了分配的挂载上的所有磁盘空间，这似乎导致连接拒绝（删除了一些提交日志，重新启动并且是能够连接）。
我使用的是DataStax AMI 2.5.1和Cassandra 2.1.7
如果我决定从头开始擦除并重新启动所有内容，我该如何确保不再发生这种情况？
答案 0 :(得分：10)
您可以尝试降低commitlog_total_space_in_mb中的cassandra.yaml设置。对于64位系统，默认值为8192MB（应在.yaml文件中注释掉...您在设置时必须取消注释）。在确定磁盘大小时，通常最好做好计划。
您可以通过在commitlog目录中运行du来验证这一点：
$ 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
...（我觉得）导致许多人将此值 WAY 设置得太高。
假设值为8，memtable_cleanup_threshold为.111。当所有memtables的占用空间超过可用总内存的比率时，将发生刷新。太多的刷新（阻塞）编写器可以方便地防止这种情况发生。使用单个/data目录，我建议将此值设置为 2 。
答案 1 :(得分：2)
除了降低BryceAtNetwork23建议的提交日志大小之外，确保不会再次发生的正确解决方案将监视磁盘设置，以便在其满了并有时间采取行动/增加时收到警报。磁盘大小。
看到您正在使用DataStax，您可以在OpsCenter中为此设置警报。我自己没有在云中使用它，但我想它会起作用。可以通过点击顶部横幅中的提醒来设置提醒 - ＆gt;管理提醒 - ＆gt;添加提醒。配置要监视的挂载和要触发的阈值。
或者，我确信有更好的工具可以监控磁盘空间。