我有一个6节点群集,每个节点的大小为1000 GB。但是一个节点的大小随机达到1000 GB。在分析中,我发现只有一个密钥空间被填充,并且只有该密钥空间大小的1个表从200 GB增加到800 GB(24小时内),这意味着有人在上面执行操作仅此表。我想弄清楚在此节点上执行了哪些操作导致该大小增加? 是否可以查看任何日志以查看执行了哪些操作?
答案 0 :(得分: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
我看到两个相对较大的分区和一个较小的分区。宾果游戏。
也许其中一些可以帮助您进入大分区的底部。
答案 1 :(得分:1)
使用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 = ?'