DSE 群集节点磁盘已满

Question

>我有一个 6 节点集群，每个节点的大小为 1000 GB。但是一个节点的大小随机达到了 1000 GB。在分析中，我发现只有一个键空间被填满，只有 1 个这个键空间大小的表从 200 GB 增加到 800 GB(在 24 小时内(，这意味着有人只在这个表上执行操作。我想弄清楚在这个节点上执行了哪些操作导致这种大小增加？ 是否有任何日志可以查看执行了哪些操作？

Answer 1

我想我会如何使用"nodetool table直方图"来证明你为表提供了大分区。然后我会转到表目录并对一些数据文件运行"sstablemetadata"，找到显示一些大分区大小的文件。

找到具有较大分区的马厩后，您可以做的一个技巧是：

sstabledump <sstable> | grep  -n ""key" :"

这将做的是每次按键切换时向您显示行号，行之间的间距越大，行数就越多。

下面是一个示例：

sstabledump aa-483-bti-Data.db | grep  -n ""key" :"
4:      "key" : [ "PROCESSING" ],
65605:      "key" : [ "PENDING" ],
8552007:      "key" : [ "COMPLETED" ],

如您所见，PENDING 和 DONE 之间的差距远大于 PROCESSING 和 PENDING (65k 行 v.s.8M 行(。所以这告诉我，与挂起相比，处理分区相对较小。唯一的谜团是完成的有多大，因为没有"结束"线。要获取总行数，请运行：

sstabledump aa-483-bti-Data.db | wc -l
16316029

总行数为16M。所以DONE从8M到16M，或大约8M线。所以 DONE 分区也很大，大约和 PENDING 分区一样大。

查看 sstablemetadata 以查看它是否与输出匹配，我发现它确实如此：

sstablemetadata aa-483-bti-Data.db
Partition Size:
Size (bytes)         | Count  (%)  Histogram
943127 (921.0 kB)    |     1 ( 33) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
129557750 (123.6 MB) |     1 ( 33) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
155469300 (148.3 MB) |     1 ( 33) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

我看到两个相对较大的分区和一个小分区。宾果游戏。

也许其中一些可以帮助您找到大分区的底部。

Answer 2

使用 DataStax Enterprise，您应该能够打开数据库审核功能。 实际上，通过配置CassandraAuditWriter的记录器类，所有活动都会写入dse_audit键空间中的audit_log表。

数据按以下主键组织：((日期，节点，day_partition(，event_time(;并具有username，table_name，keyspace_name，operation等列。

查看有关配置和查询选项的 DataStax 文档。

至于(开源(Apache Cassandra，我们使用爱立信的Cassandra Audit插件来实现此功能。 通过添加项目的 JAR，并对cassandra.yaml文件进行一些调整，您可以查看记录的audit.log，例如：

15:42:41.655 - client:'10.0.110.1'|user:'flynn'|status:'ATTEMPT'|operation:'DELETE FROM ecks.ectbl WHERE partk = ?'