Cassandra OversizedMessageException

Question

我偶尔会发现以下错误，表明消息大小过大。

允许限制 134217728（做了一个简单的数学计算）是 128Mb，我想不出是什么导致了这么大的数据。

这会影响数据的完整性吗？我可以做些什么来避免错误，例如调整 Cassandra.yaml 上的某些参数大小？

ERROR [ReadStage-1] 2024-03-29 05:36:26,158 JVMStabilityInspector.java:68 - Exception in thread Thread[ReadStage-1,5,SharedPool]
org.apache.cassandra.net.Message$OversizedMessageException: Message of size 142675369 bytes exceeds allowed maximum of 134217728 bytes
        at org.apache.cassandra.net.OutboundConnection.enqueue(OutboundConnection.java:331)
        at org.apache.cassandra.net.OutboundConnections.enqueue(OutboundConnections.java:92)
        at org.apache.cassandra.net.MessagingService.doSend(MessagingService.java:417)
        at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
        at org.apache.cassandra.net.MessagingService.send(MessagingService.java:406)
        at org.apache.cassandra.net.MessagingService.send(MessagingService.java:376)
        at org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:91)
        at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
        at org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:430)
        at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
        at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Unknown Source)

Answer 1

这会影响数据的完整性吗？

不。此异常是在

ReadStage

线程中触发的 - 这种类型的线程负责本地读取，不会以任何方式修改数据集。

我可以做些什么来避免错误，例如调整 Cassandra.yaml 上的某些参数大小？

是的。我会首先找到根本原因并解决它，而不是更改配置。我可以想到可能会触发此异常的两种情况：

1. 客户端在单个查询中扫描了大分区（超过约 128 MiB）。要验证这一点，您可以通过运行以下命令来验证最大分区未压缩大小：
   1. Cassandra 4.1.X 及更高版本：

      nodetool tablestats -s compacted_partition_maximum_bytes -t 1

   2. 以前的版本：

      nodetool tablestats | grep "Compacted partition maximum bytes" | awk '{print $5}' | sort -n | tail -1

如果您看到超过 128MiB 的分区，则可能需要检查是否有查询读取对应表中的整个分区。如果有的话，重新考虑数据模型以控制分区大小。解决此问题的一种常见解决方案是按时间或其他任意字段进行分桶分区，这样可以以平衡的方式拆分分区。

2. 客户端正在发出范围扫描。这包括读取多个分区的读取查询，例如需要

   ALLOW FILTERING

   并且不按分区键过滤的查询，在 Cassandra 中通常非常昂贵。一般来说，您可以通过

   慢查询日志

   捕获debug.log中的内容。如果是这种情况，我强烈建议考虑为每个查询建模一个表，以便所有读取都是单分区读取，并且数据库性能可以随工作负载很好地扩展。

---

最后，快速配置修复（在 Cassandra 4.X 中）是在 cassandra.yaml 中编辑以下参数并重新启动节点以应用更改：

internode_application_send_queue_reserve_endpoint_capacity_in_bytes

- 默认为 134217728

internode_application_receive_queue_reserve_endpoint_capacity_in_bytes

- 默认为 134217728

请随时查看有关节点间消息传递的官方文档这里。