问题标签 [tombstone]

InsertField 转换不适用于墓碑消息。

我正在使用 postgres 10.1 / debezium 1.2.1 版本 / kafka 2.4.1 版本

例如。

• 配置

• 插入

• 删除（墓碑消息不应用InsertField转换）

为什么会这样？是虫子吗？还是我错了？

在 Cassandra 中，墓碑用于删除，因为写入被写入不可变文件。我读到墓碑还解决了分布式系统中删除的难题。这就是我感到困惑的地方。从分布式数据库中删除存在哪些问题？例如：以一个包含节点 A、B 和 C 的 3 节点集群为例。假设节点 C 已关闭并且出现了删除。它在 A 和 B 中被标记为墓碑，成功返回给客户端。一段时间后，A 和 B 开始压实，并清除了这个墓碑。现在，当读取先前删除的值时，A 和 B 什么也不返回，而 C 返回旧值。但是在这里我读到 C 给出的值优先于空响应。

如果在该节点恢复之前已从集群的其余部分删除了墓碑记录，则 Cassandra 将已恢复节点上的记录视为新数据，并将其传播到集群的其余部分。

为什么这样做？既然仲裁节点说这个值不存在，我们为什么不把它返回给客户端呢？这可能会简化分布式系统中的删除问题，因为我们不需要在清除墓碑之前等待 gc grace 秒。

我是卡桑德拉的新手。我遇到了执行每个分区删除的情况。删除整个分区会创建墓碑吗？现在空间在删除后没有被释放。

我们的 Web 服务最近开始遇到墓碑问题。简而言之，有时我们的客户会在单个分区上发出大量删除，目前这是无法避免的。发生这种情况时，一些读取请求会变得非常慢。当此类请求的速率很高时，Cassandra 节点上的所有线程都被占用，NTR 队列很快就会被填满，然后出现超时。

以前，我们使用的页面大小为 5000，我们观察到 Cassandra 超时的间歇性峰值和墓碑读取峰值。那一刻的情况是温和的。最近，我们将页面大小设置为 1000。我们认为理想情况下，页面大小越小，超时就越少。然而，我们在此更改后观察到的是 Cassandra 超时的急剧增加。与此同时，每读的墓碑也上升了。请注意，我们没有看到导致这种情况发生大量删除的迹象。

我们无法解释这是如何发生的。所以我想了解一下墓碑是如何与活细胞一起扫描的，以及当页面尺寸较小时，每次读取的墓碑如何可能更高？

我们有一个 RF 3 的三节点 Cassandra 集群。有一个具有 SizeTieredCompaction 策略的表。在某些情况下， nodetool compact --split-output -- <keyspace> <table> 对该表执行主要压缩不会释放磁盘，但执行 nodetool garbagecollect -- <keyspace> <table> 会释放磁盘。gc_grace_seconds 设置为 1 小时，default_time_to_live 设置为 3 小时：

‍‍</p>

有谁知道原因？

提前致谢！

需要首先通过连接配置根据其中一个字段中的某些条件将记录值设为空，然后在其上应用墓碑。

假设记录的值为 {"field1" : "A", "field2" : "B", "field3" : "C"} 那么首先检查 field1 是否为 "A" 然后应用逻辑删除逻辑。

我有这个下表：

有时我会更新列或地图条目，例如：

我需要知道每个查询如何以墓碑和压缩的方式处理旧数据。

以下是我研究/建议的，但特别是在我缺乏信息的地图上。

1. 通过仅为映射中的条目生成墓碑来删除 key = 'JOE' 处的映射条目。压缩时，该值被丢弃。

2. 将键值对插入映射。旧条目在压缩时被删除，因为有一个新条目。

3. 列条目被更新，就像在 2 中一样，旧值在压缩中被删除

每种情况下的问题是，会再次写入整行还是仅写入具有较新时间戳的更新值？

我有T一个消息过期retention.ms设置为 2 天的主题。主题有压缩。

如果我将该消息读入 a KStream，然后进一步聚合到 a KTable，那么KStream和/或是否会KTable兑现 2 天到期？当消息不再在主题T中时，消息是否也会从主题中删除KStream或KTable自动删除？或者是否需要一些内务处理过程来墓碑这些消息？

我有一个表来存储无法处理的消息，并且我正在通过调度程序每 5 分钟重试一次处理消息。

成功处理消息后，表中的相应行将被删除，因此不应再次处理相同的消息。

从表查询中获取行是SELECT * FROM <table_name> ，因此，如果大量行被删除，我们将面临墓碑问题。表有时间戳作为分区键，message_name(TEXT) 作为集群键，TTL 为 7 天，gc_grace_second 为 2 天

根据我的要求，我需要删除记录，否则将处理重复记录。有什么办法可以避免墓碑问题吗？

在使用 debezium cdc 和 elasticsearch(sink) 连接器时，我遇到了这样的问题：当数据库中的数据（行）被删除时，debezium cdc 连接器会理解它并向我们的主题发送带有“__deleted”：true 属性的消息。如果我们将带有此消息的主题下沉到弹性，那么一旦它在数据库中被删除 - kafka 会创建墓碑记录，并且我们的弹性搜索接收连接器也会将其从索引中删除（如果它已经下沉到弹性）。但是，如果我们使用复合键（例如：key = id + '_' + itemId）执行一些更复杂的流，则在 elasticsearch 中不会执行此墓碑文档删除，并且此文档将永远保留在那里。

KSQLDB 中是否有办法明确提及某些消息应被视为墓碑以便从弹性中删除它们？或者也许我做错了什么？