Cassandra 当达到墓碑限制时会发生什么

根据卡桑德拉的日志（见下文），由于存在太多的

墓碑
，查询正在中止。这是因为我每周清理（删除）一次计数器过低的行。这将“删除”数十万行（用
墓碑标记它们）

如果在该表中，由于节点在清理过程中关闭而导致删除的行重新出现，则一点问题都没有，因此我将单个受影响表的
gc宽限期设置为10小时（默认为10天），以便可以相对较快地永久删除删除删除的行

无论如何，我必须将
tombstone\u failure\u阈值设置得非常高，以避免以下异常。（从10万增加到1亿）我的问题是，这有必要吗？我完全不知道什么类型的查询会被中止；插入、选择、删除

如果只是一些选择被放弃，那也没什么大不了的。但这是假设abort的意思是“capped”，因为查询会提前停止，并返回它在找到太多墓碑之前收集的任何实时数据

好吧，简单一点；当超过<代码>墓碑\u故障\u阈值时会发生什么情况

INFO [HintedHandoff:36] 2014-02-12 17:44:22,355 HintedHandOffManager.java (line 323) Started hinted handoff for host: fb04ad4c-xxxx-4516-8569-xxxxxxxxx with IP: /XX.XX.XXX.XX
ERROR [HintedHandoff:36] 2014-02-12 17:44:22,667 SliceQueryFilter.java (line 200) Scanned over 100000 tombstones; query aborted (see tombstone_fail_threshold)
ERROR [HintedHandoff:36] 2014-02-12 17:44:22,668 CassandraDaemon.java (line 187) Exception in thread Thread[HintedHandoff:36,1,main]
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
    at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
    at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:122)
    at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80)
    at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72)
    at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297)
    at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
    at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1516)
    at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1335)
    at org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
    at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
    at org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
    at org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)

忘了提；运行Cassandra版本
2.0.4
向Cassandra发出返回一系列行（或列）的查询时，它必须扫描表以收集结果集（称为切片）。现在，删除的数据以与常规数据相同的方式存储，只是在被压缩之前被标记为墓碑。但无论如何，表格阅读器必须扫描它。因此，如果你周围有成吨的墓碑，你将有大量的工作要做，以满足你表面上有限的部分

一个具体的例子：假设有两行具有集群键1和3，还有十万行具有集群键2，它们位于表中的行1和3之间。现在，当您发出
SELECT
查询，其中键为>=1和<3时，您必须扫描100002行，而不是预期的两行

更糟糕的是，Cassandra不仅扫描这些行，还必须在准备响应时将它们累积到内存中。如果事情发展得太快，这可能会导致节点内存不足错误，如果多个节点正在为请求提供服务，甚至可能导致多个故障，从而导致整个集群停机。为了防止这种情况发生，如果服务检测到数量危险的墓碑，它将中止查询。你可以自由地把它调高，但如果你的卡桑德拉堆在这些峰值期间接近耗尽，这是有风险的

此异常是在最近的修复中引入的，首次在2.0.2中提供。是描述变更试图解决的问题的错误条目。以前一切都会很好，直到您的一个节点，或者可能是几个节点，突然崩溃

如果只是一些选择被放弃，那也没什么大不了的。
但这是假设abort意味着“capped”，因为查询停止了
过早地返回它以前收集到的任何实时数据
发现的墓碑太多了

查询不会返回有限的集合，它实际上会完全删除请求。如果你想减轻压力，也许值得以与宽限期相同的节奏进行批量行删除，这样你就不会每周都有这么多墓碑涌入。
以下是完整解决方案的链接：

通过确保gc_grace_seconds设置为以更频繁的时间运行以适合您的应用程序或对某些数据使用TTL来清理墓碑。例如，默认gc_grace_秒为864000（10天）。如果您的TTL数据设置为6天，那么您可能希望将gc_grace_seconds更改为604800（7天），以便更快地删除墓碑


问候,

Ali
根据我问题中的错误日志，异常发生在暗示的切换过程中。这似乎意味着问题不仅发生在
SELECT
查询期间，而且也发生在
节点间通信期间。这是正确的吗？重要的原因是，该表有一个
复合键
，常规的select只会通过这些键中的第一个进行查询，使得在所述查询过程中的墓碑数量无关紧要。是的，暗示是节点之间交换信息的协议，但它是一个可选功能，旨在提高节点中断期间的集群性能。你可以在网站上阅读更多。提示存储在一个系统表中，因此发送一个提示涉及到对所有潜在问题进行切片。我对
HintedHandoffManager
没有深入的了解，所以我不能说在提示表中获取过多的墓碑是否表示使用模式不好。我只能说你不是唯一一个看到这些的人；有关相关讨论，请参阅。如果你能将这些崩溃与某个特定操作或周期性任务联系起来，它可能会给你一个线索，让你知道为什么一开始会产生这么多提示；我使用了
ONE
的写一致性，因此如果我正确理解
hinddehandoff
就不应该起作用了。。。可能是因为在一个旧的键空间中写入了内容，但这只是一个未经教育的猜测。@natli到您的最后一条评论：即使CL为1 to writes，如果拥有令牌的节点关闭了，C*会在它返回时使用暗示的切换来更新它。这不是会更快地创建墓碑吗？在发生压实/修复事件之前，它们仍然不会被移除
cqlsh:results> alter table example with gc_grace_seconds = 10000;