自从从 Cassandra 版本 2.2.7 升级到 3.0.8 以来，我几乎每隔几分钟就会在每个节点上收到以下错误。对于 173.170.147.120 的节点（IP 是假的，我替换了真实的），错误system.log将是：

据我所知，在所有此类错误中总是存在[id: <...>, /<broadcast_address>:<some_port> :> /<listen_address>:<native_transport_port>. 并且broadcast_address总是listen_address属于当前节点地址。

此外，无论是否有连接的客户端，都会出现此问题。

此类错误的可能原因是什么，我该如何解决？

任何想法将不胜感激。

升级版。我想，这个问题可能与旧的密钥空间迁移有关，但即使只有新创建的 KS 也会重现。

我已经搜索过这个问题的以前版本，但似乎没有一个适合我的情况。我有一个运行 2.0.x 的现有 Cassandra 集群。我被分配了新的虚拟机，所以我不想升级我现有的 Cassandra 节点——而是我想迁移到 a) 新的虚拟机和 b) 更新的 Cassandra 版本。

1. 我知道就地升级，我会升级到最新的 2.0.x，然后升级到最新的 2.1.x。AFAIK，这里没有 SSTable 不一致。如果我通过添加新节点走这条路线，我假设我会按照 datastax 说明添加新节点/停用旧节点？

2. 鉴于上述情况，是否可以从 2.0.x 迁移到 3.0.x？我知道 SSTable 格式不同；但是，如果我要添加新节点（而不是在磁盘上重新使用 SSTables），这有关系吗？

在我看来，#2 必须起作用——否则，这意味着任何需要 SSTable 升级的升级都需要同时使所有节点脱机；否则，有时会在同一集群中运行混合的 2.xx 和 3.0.x 版本。

我完全错了吗？有没有人有这样做的经验？

尝试在 Cassandra 3 中编写时出现以下错误。

Cassandra 在一致性 ONE 的写入查询期间失败（需要 1 个响应，但只有 0 个副本响应，1 个失败）

尝试将数据插入具有物化视图的表时会出现该错误。

大小分层压缩至少需要与最大列族大小一样多的可用磁盘空间进行压缩。Leveled Compaction 需要的压缩空间要少得多，只有 10 * sstable_size_in_mb。

DTCS 空闲磁盘要求是像 STC 还是更糟？它是否取决于 max_sstable_age_days 参数？

我想通过 JDBC 步骤从 SoapUI 连接到 Cassandra DB。并且还想使用 cql 进行不同的查询。 注意：我阅读了关于类似问题的现有答案，但它们对结果没有帮助。

前提条件：Cassandra DB（Cassandra 版本 3.0.3），在 IP 类似 10.xxx、端口 9042 的服务器上

完成：我将以下罐子添加到<soapui>../bin/ext：

在 SoapUI 中，在配置中，我配置了：

但试图测试连接 - 我只收到

问题：如何解决这个问题，建立连接并对数据库进行查询？

我有一个运行 Cassandra 3.9 的 4 个节点的小型 Cassandra 集群。

我将 4 个 IP 地址传递给connect()函数，当我检查连接时netstat -a4n | grep 9042，我可以看到它们都已连接。请注意，无论我将 1 个 IP 还是 4 个传递给connect()，一旦完全连接，结果是相同的，包括到 10.0.1.1 节点的双重连接......（10.0.1.1 和 10.0.1.3 是种子，但不知何故只有 10.0. 1.1有一个双重连接，所以我不太清楚为什么会发生这种情况，我试图洗牌用于连接的IP列表，同样，它最终没有任何区别。）

当我查看 的输出时nodetool status，它看起来相当不错：

（注意：我删除了 ID，它们在这里没有用）。

然而，在网络方面，当我查看传输到这些机器的数据量时，我发现了巨大的差异。我使用该iptables -L -nvx命令，令我惊讶的是，我向第一个 Cassandra 节点发送了大约 3 倍的数据包和近 20 倍的数据：

（6,856 / 2,736 = 2.51 和 13,581,751 / 806,023 = 16.85）

我想在某种程度上，只要节点不忙，这并不重要，但我仍然想知道为什么我会看到如此巨大的差异？为什么不是所有 4 个连接都以相似的级别参与？

我在 ec2 中运行一个 26 节点集群，分布在 4 个区域 - us-east-1、us-west-2、eu-west-1 和 ap-southeast-1。我注意到有时节点需要很长时间才能启动，并且问题在 ap-southeast-1 中似乎特别严重。例如，今天仅重新启动一个节点就需要 4 个多小时。发生这种情况时，cassandra (system.log) 记录的最后一件事是：

最终它继续初始化我自己的列族，但我不明白什么需要这么长时间。这个特定节点上有大约 900G 的数据，使用 3.2T EBS 卷。

虽然这种情况正在发生，但似乎很少有资源争用。网络 i/o 似乎没有超过 1Mb/s。数据量和提交日志基本上都是0 i/o。CPU 使用率在 25%-50% 范围内。看着strace，似乎有大量的getdents系统调用，但这似乎不会引起问题。

什么可以解释这么长的启动时间？

集群信息

• 卡桑德拉 DDC 3.5
• EC2MultiRegionSnitch
• m4.xlarge，移动到 c4.4xlarge

架构信息

• 3 个 CF，全部“写入一次”（即不更新），1 周 ttl，STCS（默认）
• 没有二级索引

我想在 Spring Boot 项目中使用 Cassandra 3.x。我发现 Spring Data Cassandra 项目的当前发布版本只支持 Cassandra 2.x。所以我想使用 DataStax Driver 而不是 Spring Data Cassandra 项目。我添加了

作为依赖。现在我可以将值插入到 Cassandra 集群上的键空间中。但是在为 REST 控制器运行测试时出现错误

所以我加了

作为依赖项，错误消失了。但是现在所有测试都使用

或者

失败。但是使用

按预期工作。我假设 Spring Boot 的依赖项和我作为依赖项添加的 Netty 版本存在一些冲突。

我发现 DataStax Cassandra 驱动程序的最新版本可以在没有额外的 Netty 依赖的情况下工作，它是 2015 年 3 月发布的，不支持 Cassandra 3。使用这个驱动程序一切正常，但我不想使用那个老司机

更新：我删除了 DataStax 驱动程序依赖项并尝试使用 Spring Data Cassandra 的 1.5.0.M1 版本，并在 buildscript 中覆盖了 Spring、Spring Data Cassandra 和 Cassandra 驱动程序版本。

这导致了以下错误：

使用 Cassandra 功能时。当我再次包含 Netty 时，Cassandra 功能有效，但我的测试正在使用TestRestTemplate.put并且.post不再运行。我再次尝试升级到 Spring Boot 版本 2.0.0.BUILD-SNAPSHOT，其中还包括 Spring Data Cassandra 1.5.0.M1。现在，当我启动应用程序并使用 DataStax 驱动程序功能时，我会得到与以前相同的 NoClassDefFoundError。添加 Netty 作为依赖项会再次杀死我基于 TestRestTemplate 的单元测试......

更新：TestRestTemplate不起作用，因为 Spring Boot 将其配置为Netty4ClientHttpRequestFactory在类路径上找到 Netty 时使用，并且Netty4ClientHttpRequestFactory似乎不起作用。

请参阅https://github.com/spring-projects/spring-boot/issues/7240 和https://jira.spring.io/browse/SPR-14860

有关修复，请参阅我对这个问题的回答。

我在 Cassandra 3.0 版及更高版本上面临有关 Cassandra 延迟度量标准的问题。

之后，我发现与此问题相关的错误如下 URL。 https://issues.apache.org/jira/browse/CASSANDRA-11752

细节表明这个问题已经在 C* 版本 2.2.8、3.0.9、3.8 中得到解决。但是在我在 Apace Cassandra 3.0.9 版本上进行测试后，延迟的结果仍然显示为平线。

我使用 jconsole 来监控 Cassandra 的读写延迟。当我运行负载测试时，它一直显示相同的延迟值。而 M1_rate 和请求计数正常移动。

有什么解决这个问题的建议吗？

我们有一个活动指标页面，用户可以在其中选择一个日期期间并查看其他用户的汇总活动（按操作），并可选择按 4 或 5 个字段过滤所有内容。动作按顺序发生，但其中一个字段是Tags，用户可以随时更改旧动作的标签。数据位于 Cassandra 3.7 中，分区键为(company_id, action_year, action_week). 每周我们有大约 70k 个操作（每个操作有 20 列带有long或int数据，每个操作都带有分区键 plusaction_timestamp和action_key行键）。

在第一个版本中，我们查询一段时间内的完整操作，并在内存中进行所有聚合和过滤。当用户选择几个星期时，整个请求大约需要 10 或 15 秒。我们预计将扩展到成千上万请求这些分析的用户，这些分析应该可以作为近乎实时的分析。

我们曾想过使用“允许过滤”将过滤移至 C*，但 WHERE 子句似乎非常有限。我们也担心标签的频繁更新。

在这里使用 C* 的正确方法是什么？