问题标签 [tombstone]

简单查询：- 我用 gc_grace_seconds 10 天删除了 Scylla 上的数据。Scylla 创建了墓碑并等待 gc_grace_seconds 过期。

现在，我在删除后的第二天运行了主要压缩（gc_grace_seconds 到期还剩下 8 天）。

1）什么压缩会做？它将考虑所有墓碑并清除2天前删除的内容？

2) 我应该在运行主要压缩之前更改 gc_grace_seconds=0 吗？

请帮忙

提前致谢。

卡桑德拉版本 3.11.3

我有一些集合和列表集合的记录。使用带有添加/删除数据的集合似乎没有或非常有限的墓碑创建。然而，使用列表列似乎会为每个查询创建一个墓碑。

我的印象是这个bug已经修复了。
难道我做错了什么？

这样做 10k 次不会生成任何墓碑：（假设之前不存在分区）

因此，此查询工作正常：

这样做 10k 次会生成很多墓碑：（假设之前不存在分区）

更新后，由于墓碑太多，此查询失败：

我有一个删除用例较少的 cassandra 集群。我在我的 system.log 中发现“ Read 10 live and 5645464 tombstones cell in keyspace.table ”是什么意思？请帮助理解。

谢谢。

我们在生产环境中部署了一个全局 Apache Cassandra 集群（节点：12，RF：3，版本：3.11.2）。我们遇到了一个问题，即在列族上运行主要压缩无法从一个节点（3 个副本中）清除墓碑，即使元数据信息显示最小时间戳已通过 gc_grace_seconds 设置在表上。

这是稳定的元数据输出

到目前为止，这是我们尝试过的，1）使用较低的 gc_grace_seconds 进行主要压缩 2）nodetool 垃圾收集 3）nodetool 擦洗

以上方法都没有帮助。同样，这只发生在一个节点上（总共 3 个副本中）

我正在为哈希表编写一个类。哈希表是我编写的一个类中的对象数组，称为HashVariable. HashVariable仅有两个属性，一个名称和一个整数值。我知道如果我从表中删除一个项目，我将不得不用“墓碑”替换它，但我不确定我应该使用什么作为墓碑。

我没有真正尝试过，因为我不确定我能做什么。我可以尝试将一个字符转换为HashVariable并将其插入到数组中，但我不能那样转换它。

我有一个 HdfsSink 连接器，它与分布式 kafka 连接器一起使用，有 2 个任务。其中一个失败了，这是失败的状态：

当我通过官方的ConfluentTombstoneHandler使用以下命令安装带有 confluent-hub 的 tombstonehandler 时，就会发生这种情况：

我有三个节点的 Cassandra 集群。我想对每个节点中包含大约 1 TB 数据的特定表执行清理任务。

表包含多行带有 date_created(timestamp) 的订阅者，我想清除所有最新条目 (date_created) 早于 7 天的订阅者行。

例如 - 在附加的上述数据示例中，我们必须删除订阅者 2 的所有行，而如果在 2019 年 12 月 10 日运行，订阅者 2 的所有行都将被保留。

我们有大约 10 M 的订阅者，为了获得记录总数，选择 count(*) 查询抛出异常

ReadTimeout：来自服务器的错误：代码 = 1200 [协调节点超时等待副本节点的响应]消息 =“操作超时 - 仅收到 0 个响应。” info={'received_responses': 0, 'required_responses': 1, '一致性': 'ONE'}

我应该使用什么方法来读取 Cassandra，因为这不能作为 3 TB 的巨大数据在内存中执行。

我的输入是1:45$，我们正在处理消息，接下来我将更新1:null.

我仍然看到1:45$主题中的 以及1:null（我可以看到两条消息）

我希望输出1:null在同一个主题中。

我用过这段代码：

但是在我的情况下我没有发现任何压缩并且需要一些输入来使值成为1::null

我在 Kafka 主题中有消息，压缩如下

稍后，一些更多的值被添加到相同的键

我希望从上述消息中实现的愿望来自以下主题

任何建议如何将值组合到主题中的相同键

我们有一个运行 Cassandra 2.2.14 的新集群，并留下了压缩以“自行解决”。这是在我们的 UAT 环境中，所以负载很低。我们运行 STCS。

我们看到永远在增长的墓碑。我知道一旦 sstable 符合压缩条件，压缩最终会处理数据。这对我们来说发生的频率不够高，所以我启用了一些设置作为测试（我知道它们很激进，这纯粹是为了测试）：

这确实导致了一些压缩的发生，但是删除的墓碑数量很少，也没有低于阈值 (0.2)。应用这些设置后，我可以从 sstablemetadata 中看到：

请注意，这只是一个 CF，而且还有更糟糕的 CF（90% 的墓碑等）。以此为例，但所有 CF 都遭受相同的症状。

表格统计：

显而易见的答案是墓碑不符合移除条件。

gc_grace_seconds 设置为 10 天，并且没有被移动。我将其中一个 sstable 转储为 json，我可以看到可追溯到 2019 年 4 月的墓碑：

所以我不相信 gc_grace_seconds 是这里的问题。我已经对列族文件夹中的每个 Data.db 文件（仅单个 Data.db 文件，一次一个）运行了手动用户定义的压缩。压缩运行，但墓碑值几乎没有变化。旧数据仍然存在。

我可以确认维修已经发生，实际上是昨天。我还可以确认维修一直在定期进行，日志中没有显示任何问题。

所以维修没问题。压实很好。我能想到的只是重叠的 SSTables。

最后的测试是对列族运行完全压缩。我使用 JMXterm 在 3 个 SSTables 上执行了用户定义（不是 nodetool compact）。这导致了一个单一的 SSTable 文件，其中包含以下内容：

如果我查找上面的示例 EPOCH (1566793260)，它是不可见的。也不是关键。所以它被压缩了，或者 Cassandra 做了什么。在 1.2 亿行转储中，包含 tombstone ("d") 标志的总行数为 1317。EPOCH 值均在 10 天内。好的。

所以我假设 -6 值是一个非常小的百分比，并且 sstablemetadata 在显示它时遇到问题。那么，成功对吗？但是要完全压实才能移除旧墓碑。据我所知，完全压实只是最后的努力。

我的问题是——

1. 如何确定重叠的 sstables 是否是我的问题？我看不出数据不会压缩的任何其他原因，除非它与重叠相关。
2. 如何在不执行完全压缩的情况下解决重叠的 sstable？恐怕这只会在几周后再次发生。我不想陷入不得不定期执行完全压实以防止墓碑陷入困境。
3. 创建重叠 sstables 的原因是什么？这是数据设计问题还是其他问题？

干杯。