Question

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

Answer 1

我猜我将如何使用“ nodetool tablehistograms”来证明您的表具有较大的分区。然后，我将转到表目录，并对某些数据文件运行“ sstablemetadata”，找到那些显示较大分区大小的文件。

一旦找到具有更大分区的sstables，您可以做的一个窍门是：

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

该操作将为您显示每次按键切换时的行号，行之间的间隙越大，行数越多。

这里是一个例子：

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

如您所见，PENDING和COMPLETED之间的距离比PROCESSING和PENDING大得多（65k行与8M行）。因此，这告诉我，与PENDING相比，PROCESSING分区相对较小。唯一的谜团是因为没有“结束”行，所以COMPLETED有多大。要获取总行数，请运行：

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

总行数为16M。因此，COMPLETED从8M增长到16M，或大约8M线。因此，COMPLETED分区也很大，大约与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，您应该能够打开Database Auditing功能。实际上，通过配置记录器类CassandraAuditWriter，所有活动都将被写入audit_log键空间中的dse_audit表中。

数据是通过以下主键组织的：（（日期，节点，day_partition），event_time）；并具有username，table_name，keyspace_name，operation等列。

查看DataStax docs上的配置和查询选项。

对于（开源）Apache Cassandra，我们使用Ericsson's 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 = ?'

DSE群集节点磁盘已装满

2 个答案: