我在Cassandra的一个表中插入了10K个条目，在单个分区下TTL为1分钟。
成功插入后，我尝试从单个分区读取所有数据，但它会抛出如下错误，
WARN [ReadStage-2] 2018-04-04 11:39:44,833 ReadCommand.java:533 - Read 0 live rows and 100001 tombstone cells for query SELECT * FROM qcs.job LIMIT 100 (see tombstone_warn_threshold)
DEBUG [Native-Transport-Requests-1] 2018-04-04 11:39:44,834 ReadCallback.java:132 - Failed; received 0 of 1 responses
ERROR [ReadStage-2] 2018-04-04 11:39:44,836 StorageProxy.java:1906 - Scanned over 100001 tombstones during query 'SELECT * FROM qcs.job LIMIT 100' (last scanned row partion key was ((job), 2018-04-04 11:19+0530, 1, jobType1522820944168, jobId1522820944168)); query aborted
我知道墓碑是sstable中的标记而不是实际的删除。
所以我使用 nodetool
执行压缩和修复即使在我从表中读取数据之后，它也会在日志文件中抛出相同的错误。
1）如何处理这种情况？
2）有人可以解释为什么这种情况发生了，为什么压缩和修复都没有解决这个问题？
谢谢，
哈利
答案 0 :(得分：3)
在表格的gc_grace_seconds设置指定的时间段之后，真正删除了墓碑（默认情况下为10天）。这样做是为了确保在删除时关闭的任何节点将在恢复后获取这些更改。以下是详细讨论此内容的博文：from thelastpickle (recommended)，1，2以及DSE documentation或Cassandra documentation。
您可以将单个表上的gc_grace_seconds选项设置为较低值，以便更快地删除已删除的数据，但这仅适用于具有TTL数据的表。您可能还需要调整tombstone_threshold＆amp; tombstone_compaction_interval表选项可以更快地执行压缩。有关这些选项的说明，请参阅this document或this document。
答案 1 :(得分：0)
新的cassandra支持。
$ ./nodetool garbagecollect
此命令“将内存传输到磁盘，重新启动之前”
$ ./nodetool drain # "This closes connection after that, clients can not access. "
关闭cassandra，然后再次重新启动。 “耗尽后应重新启动。”
**您无需排空！但是，要视情况而定。这些是额外的信息。