我正在AWS上运行双节点Datastax AMI集群。昨天,卡桑德拉开始拒绝一切的联系。系统日志没有显示。经过大量的修补,我发现提交日志已经填满了分配的挂载上的所有磁盘空间,这似乎导致连接拒绝(删除了一些提交日志,重新启动并且能够连接)。
我在使用DataStax AMI 2.5.1和Cassandra 2.1.7
如果我决定从头开始擦除并重新启动所有内容,我该如何确保不再发生这种情况?
您可以尝试降低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
...(我觉得)导致许多人设置这个值太高了。
假设值为8,则memtable_cleanup_threshold
为.111
。当所有memtables的占用空间超过可用总内存的比率时,将发生刷新。太多的刷新(阻塞)编写器可以方便地防止这种情况发生。使用单个/data
目录,我建议将此值设置为2。
除了降低BryceAtNetwork23建议的commitlog大小之外,确保它不会再次发生的正确解决方案还将监视磁盘设置,以便在它充满并有时间执行/增加磁盘大小时收到警报。
看到您正在使用DataStax,您可以在OpsCenter中为此设置警报。我自己没有在云中使用它,但我想它会起作用。可以通过单击顶部横幅 - >管理警报 - >添加警报中的警报来设置警报。配置要监视的挂载和要触发的阈值。
或者,我确信有更好的工具可以监控磁盘空间。