墓碑与节点工具和修复

Question

我在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

我知道墓碑是马厩中的一个标记，而不是实际的删除。

所以我使用nodetool进行了压缩和修复

即使在那之后，当我从表中读取数据时，它也会在日志文件中抛出相同的错误。

1) 如何处理这种情况？

2)有些人可以解释为什么会出现这种情况，为什么不压缩和修复没有解决这个问题？

Answer 1

逻辑删除在表设置指定的时间段后gc_grace_seconds实际删除(默认为 10 天)。 这样做是为了确保删除时关闭的任何节点在恢复后都会拾取这些更改。 以下是详细讨论此问题的博客文章：来自thelastpickle(推荐)，1,2和DSE文档或Cassandra文档。

您可以将单个表上的gc_grace_seconds选项设置为较低的值，以更快地删除已删除的数据，但应仅对具有 TTL 数据的表执行此操作。 您可能还需要调整tombstone_threshold和tombstone_compaction_interval表选项以更快地执行压缩。 有关这些选项的说明，请参阅此文档或此文档。

Answer 2

新的卡桑德拉支持 .

$ ./nodetool garbagecollect

在此命令"重新启动之前将内存传输到磁盘"之后

$ ./nodetool drain    # "This closes connection after that, clients can not access. "

关闭 cassandra 并重新启动。 "你应该在排水后重新启动。">

**你不需要排水，！但是，取决于情况。这些是额外的信息。