我们有一个cassandra测试数据库，它已经运行了几年了。今天它开始使用大量的CPU。重新启动后，它再次发生。因为这是一个有很多垃圾的测试数据库--我只是想从最大的表中清除数据，凭直觉可以解决这个问题。这是一个运行在一台服务器上的示例。找出最大的表的最好方法是什么，以便我可以截断它们？
js81xvg61#
我遇到过使用nodetool的解决方案，在那里你会得到大量的转储，查看使用的块，等等。这感觉像是有很多工作要筛选，所以我想出的最好的解决方案是直接进入文件系统（见下文）。首先，我检查了日志，发现一些条目引用了我的数据似乎在哪里。
ubuntu@ip-xyz:/$ cd /var/lib/cassandra/data/ ubuntu@ip-xyz:/var/lib/cassandra/data$ du -h --max-depth=2 | grep M 2.5M ./tot_build_test/app_metering_id_activity_ts-55ac79a0d93a11eca73b09ac53055308 2.5M ./tot_build_test/id_by_fingerprint-55c3f940d93a11eca73b09ac53055308 2.5M ./tot_build_test/app_metering_by_id-5664cd20d93a11eca73b09ac53055308 7.7M ./tot_build_test/onboarding_metrics_by_id-5552c0e0d93a11eca73b09ac53055308 5.5M ./tot_build_test/onboarding_metrics_by_metric_ts-55f54270d93a11eca73b09ac53055308 9.6M ./tot_build_test/app_tx_activity_ts-55d97d10d93a11eca73b09ac53055308 1.4M ./tot_build_test/api_metrics_by_id-b6e4336086d811edafd7af4d63a260a1 37M ./tot_build_test/metrics_by_metric_ts-b82351c0e8e511ec95cbc90b0480fbc7 53M ./tot_build_test/app_user_activity_ts-56106b90d93a11eca73b09ac53055308 30M ./tot_build_test/metrics_by_id-b8581d60e8e511ec95cbc90b0480fbc7 156M ./tot_build_test 1.4M ./system 21M ./tot_localhost/metrics_by_id-9c91c090db7f11eca298336e81c9f198 2.1M ./tot_localhost/id_by_fingerprint-fdae3ae0d93911eca73b09ac53055308 26M ./tot_localhost/metrics_by_metric_ts-9c404530db7f11eca298336e81c9f198 2.2M ./tot_localhost/account_metrics_by_id-fde29150d93911eca73b09ac53055308 4.8M ./tot_localhost/onboarding_metrics_by_metric_ts-ff9d87c0d93911eca73b09ac53055308 21M ./tot_localhost/job_activity-f091ca10a10811edb5af9735d3abddfc 2.2M ./tot_localhost/account_metrics_by_metric_ts-fcec7180d93911eca73b09ac53055308 6.6M ./tot_localhost/onboarding_metrics_by_id-fd0acef0d93911eca73b09ac53055308 1.8M ./tot_localhost/app_metering_by_id-fe1cb420d93911eca73b09ac53055308 1.8M ./tot_localhost/app_metering_id_activity_ts-fd61a180d93911eca73b09ac53055308 44M ./tot_localhost/app_user_activity_ts-fcd39250d93911eca73b09ac53055308 8.9M ./tot_localhost/app_tx_activity_ts-fd969430d93911eca73b09ac53055308 144M ./tot_localhost 301M .
在我们的例子中，big在MB范围内，但其他人可能需要更改我在上面的grep中使用的过滤器。无论如何，从这里我可以手动将密钥空间（上面路径的第一部分）和表名加上散列放在一起。我的计划是使用一个很好的老式编辑器，使用上面提到的keyspace.table寻址来组装一个TRUNCATE命令列表，例如：TRUNCATE tot_localhost.app_user_activity_ts;运行TRUNCATE命令后，我有点困惑，它似乎什么也没做。重新运行du-同样的结果。什么？！基本上cassandra是在保护我不傻-为那些表创建快照。不要担心nodetool有一个命令可以删除快照，它非常容易运行（您可能不希望在生产环境中运行此命令）：
TRUNCATE tot_localhost.app_user_activity_ts;
du
ubuntu@ip-xyz:/var/lib/cassandra/data$ nodetool clearsnapshot Requested clearing snapshot(s) for [all keyspaces] ubuntu@ip-xyz:/var/lib/cassandra/data$ du -h --max-depth=2 | grep M 5.5M ./tot_build_test 1.2M ./system/size_estimates-618f817b005f3678b8a453f3930b8e86 1.8M ./system 1.1M ./system_schema 3.4M ./tot_localhost 12M .
啊...这才像话！这感觉有点野蛮，但我很快就到了我需要去的地方。有没有更好的方法？
vxbzzdmp2#
最简单的方法就是检查你的data_file_directories位置，找出占用空间最大的是什么，正如你所提到的，永远不要害怕运行nodetool clearsnapshot来清除不需要的快照（和截断的自动快照，等等）。
data_file_directories
nodetool clearsnapshot
x33g5p2x3#
获取节点上表的大小的一般方法是运行nodetool tablestats，然后解析命令的输出，按大小顺序对表进行排序。如果集群是单节点集群，可以简单地编写一个shell脚本，按照目录大小列出表。类似下面的脚本将列出10个最大的表：
nodetool tablestats
$ cd /path/to/cassandra/data_directory && du -sk */* | sort -nr | head
请注意，使用这种方法将包含备份（snapshots/），因此您需要考虑它。
snapshots/
3条答案
按热度按时间js81xvg61#
我遇到过使用nodetool的解决方案，在那里你会得到大量的转储，查看使用的块，等等。这感觉像是有很多工作要筛选，所以我想出的最好的解决方案是直接进入文件系统（见下文）。
首先，我检查了日志，发现一些条目引用了我的数据似乎在哪里。
在我们的例子中，big在MB范围内，但其他人可能需要更改我在上面的grep中使用的过滤器。
无论如何，从这里我可以手动将密钥空间（上面路径的第一部分）和表名加上散列放在一起。
我的计划是使用一个很好的老式编辑器，使用上面提到的keyspace.table寻址来组装一个TRUNCATE命令列表，例如：
TRUNCATE tot_localhost.app_user_activity_ts;运行TRUNCATE命令后，我有点困惑，它似乎什么也没做。重新运行
du-同样的结果。什么？！基本上cassandra是在保护我不傻-为那些表创建快照。不要担心nodetool有一个命令可以删除快照，它非常容易运行（您可能不希望在生产环境中运行此命令）：
啊...这才像话！
这感觉有点野蛮，但我很快就到了我需要去的地方。有没有更好的方法？
vxbzzdmp2#
最简单的方法就是检查你的
data_file_directories位置，找出占用空间最大的是什么，正如你所提到的，永远不要害怕运行nodetool clearsnapshot来清除不需要的快照（和截断的自动快照，等等）。x33g5p2x3#
获取节点上表的大小的一般方法是运行
nodetool tablestats，然后解析命令的输出，按大小顺序对表进行排序。如果集群是单节点集群，可以简单地编写一个shell脚本，按照目录大小列出表。类似下面的脚本将列出10个最大的表：
请注意，使用这种方法将包含备份（
snapshots/），因此您需要考虑它。