Question

Cassandra系统日志：

ERROR [ReadStage:8468] 2016-05-09 08:58:28,029 SliceQueryFilter.java (line 206) Scanned over 100000 tombstones in AAAAA.EVENT_QUEUE_DATA; query aborted (see tombstone_failure_threshold)
ERROR [ReadStage:8468] 2016-05-09 08:58:28,029 CassandraDaemon.java (line 258) Exception in thread Thread[ReadStage:8468,5,main]
java.lang.RuntimeException: org.apache.cassandra.db.filter.TombstoneOverwhelmingException
at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2008)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

申请日志：

! java.net.SocketException: Broken pipe
! at java.net.SocketOutputStream.socketWrite0(Native Method) ~[na:1.8.0_45]
! at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) ~[na:1.8.0_45]
! at java.net.SocketOutputStream.write(SocketOutputStream.java:153) ~[na:1.8.0_45]
! at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) ~[na:1.8.0_45]

我还不知道确切的原因。我的猜测是许多对Cassandra的删除调用可能导致这种情况的触发器。现在任何建议对我都非常有帮助。非常感谢。

Answer 1

临时解决方法，您可以在for (int x = 0; x < length; x++) { for (int y = 0; y < height; y++) { if (!seed[x, y] && !seas[x, y]) { lakes[x, y] = true; } } }中增加tombstone_failure_threshold。

我想从cassandra.yaml名称来看，您已经实现了一个队列。这是anti-pattern，这也会导致您的解释。这将继续变得糟糕，并导致很多GC风格问题和性能问题。

虽然知道这对你今天没有什么帮助。我建议您提高失败阈值（上图）并更新compaction strategy以便将来提供帮助。这是一个想法：

AAAAA.EVENT_QUEUE_DATA

但您希望在应用程序中进行更改。请记住，更具侵略性的墓碑删除可能会导致删除失败＆＃34;但它不太可能而且比失败更好。

Answer 2

当你＆＃34;删除＆＃34;时会生成墓碑。您的数据，它们代表删除功能的逻辑标记。这是一个帮助你对抗幽灵列的机制的一部分。如果您删除了大量数据，您可以轻松地发现墓碑警告甚至错误（就像您的情况一样）。您的表上有一个gc_grace期间设置，用于定义逻辑删除的保留时间。另外，尽量避免选择所有内容（使select语句定位实际数据而不是范围查询）。

Cassandra：READSTAGE的TombstoneOverwhelmingException与破坏的管道异常之间是否存在关系？

2 个答案: