Tombstone vs nodetool和修复

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

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

所以我使用 nodetool 进行了 compaction 和 repair

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

1) 如何处理这种情况？

2) 有人能解释一下为什么会发生这种情况吗？为什么压缩和修复没有解决这个问题？

Answer 1

在gc_grace_seconds table 设置指定的时间段后（默认为 10 天），Tombstone 将被真正删除。这样做是为了确保在删除时关闭的任何节点都会在恢复后拾取这些更改。以下是详细讨论此问题的博文：from thelastpickle (recommended)、1、2 和 DSE documentation 或 Cassandra documentation。

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

Answer 2

新的 cassandra 支持。

$ ./nodetool garbagecollect

此命令后“将内存转移到磁盘，重新启动之前”

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

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

** 你不需要排水，！但是，视情况而定。！这些是额外的信息。