问题标签 [cassandra-2.2]

请帮助我了解我错过了什么。我在带有LIMIT和ORDER BY DESC子句的SELECT上看到一个集群节点的奇怪行为：

追踪（仅部分）：

…<br> 发送 REQUEST_RESPONSE 消息到 /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] | 2016-02-29 22:17:25.117000 | 10.0.23.15 | 7862
将 REQUEST_RESPONSE 消息发送到 /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] | 2016-02-29 22:17:25.136000 | 10.0.25.57 | 6283
将 REQUEST_RESPONSE 消息发送到 /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] | 2016-02-29 22:17:38.568000 | 10.0.24.51 | 457931
…

10.0.25.56 - 协调节点
10.0.23.15, 10.0.24.51 , 10.0.25.57 - 有数据的节点

协调器比其他节点晚 13 秒从 10.0.24.51 获得响应！为什么这样？我该如何解决？

分区键（uid = 0x50236b6de695baa1140004bf）的行数约为 300。

如果我们使用ORDER BY ASC（我们的聚类顺序）或LIMIT值小于此分区键的行数，一切都很好。

Cassandra (v2.2.5) 集群包含 25 个节点。每个节点拥有大约 400Gb 的数据。

集群放置在 AWS 中。节点均匀分布在 VPC 中的 3 个子网中。节点的实例类型为 c3.4xlarge（16 个 CPU 内核，30GB RAM）。我们使用 EBS 支持的存储（1TB GP SSD）。

键空间 RF 等于 3。

列族：

节点工具 gcstats (10.0.25.57):

节点工具 gcstats (10.0.23.15):

节点工具 gcstats (10.0.24.51):

我想创建一个具有固定行数的表（比如说 N），如果添加了第 N+1 行，则将删除第 1 行。

这是表格，我用于存储来自图形分析的最后 N 个最佳结果：

我在 DataStax 阅读了有关过期数据的信息，但发现只有 TTL 过期。所以我决定按照以下方式进行。

我的方法A：

每次想要添加新结果时，都会检索最旧行的 id。

..以及当前的行数..

因此，如果 count >= N，则删除最旧的行并添加最新的行...

这种方法的问题在于，第一次选择不是原子操作以及随后的批处理。因此，如果任何其他工作人员删除了 select 和 batch 之间最旧的行，或者超过了 N，那么这将不起作用。

我的方法B：

相同的第一步...

然后尝试一次又一次地删除最旧的行，直到成功..

在这种方法中，在检查 count < N 之前，在数据库中超过 N 仍然存在问题。

你能给我指出正确的解决方案吗？

我们有一个带有 RF 3 的 3 节点集群。

一旦我们从集群中耗尽一个节点，我们就会看到很多：

我们所有的写入和读取都具有一致性级别 QUORUM 或 ONE，因此在一个节点关闭的情况下，一切都应该完美运行。但是只要节点关闭，就会抛出异常。

我们使用 Cassandra 2.2.4 + Java Cassandra Driver 2.1.10.2

以下是我们创建集群的方式：

CONTACT_POINTS 是节点的 3 个公共 ip 的字符串数组。

几个月前，集群在暂时只有 2 个节点的情况下运行良好，但由于未知原因，情况不再如此，我的想法已经不多了 :(

非常感谢你的帮助！

我们有一个运行 Cassandra 2.2.5 的 24 节点 AWS 集群 (i2.xlarge)。我们有一张大桌子和几张小桌子。大表占用了大部分磁盘空间。磁盘使用量意外增加。

我们正在使用 LCS，并且注意到 SSTables 没有进入更高的级别。

表上的 cfstats 向我们展示了 SSTables 似乎没有被压缩到更高的级别：

数据集大约在一个月前完成加载，磁盘使用率为 60-65%。我们正在更新数据集，磁盘使用量每天增加约 0.5%。我们目前看到节点上 75-80% 已满。正在更新行，但没有新行，也没有删除行。所以我们没想到磁盘使用率会上升。我们最好的猜测是压缩不再从 sstables 中删除重复项。

当试图对数据集（nodetool compact）强制压缩时，我们收到有关磁盘空间不足的错误。

LCS 上的文档声称“只需要保留 10 倍 sstable 大小的足够空间，以供压缩临时使用。” 在我们的例子中，压缩看起来需要 1977x 160MB。

我们确实遇到了重置 LCS 压缩级别的建议： Leveled Compaction Strategy with low disk space

但是，当我们在具有相同问题的较小数据集的较小集群上尝试此操作时，它进行的压缩似乎也需要大量空间，而不仅仅是承诺的 1.6G。

前：

执行 sstablelevelreset 后：

之后的第一次压缩开始压缩 21698490019 字节。这似乎是大约 129 sstables 的数据。

在小集群上，我们有足够的额外磁盘空间，但在大集群上，似乎没有足够的空间来强制压缩或使用 sstablelevelreset 实用程序重新开始压缩。

压缩完成后，这是 sstable 级别的样子（请注意，文档会不断更新，但不会添加到数据库中）：

我们还能做些什么来尝试恢复磁盘空间？或者至少可以防止磁盘使用量攀升？

该表定义如下：

来自节点之一的完整 cfstats：

这是关于正在发生的压实的一些错误。这里有一个特别的：

如果您注意到有 23 个 sstable 被压缩：一个来自 2 级，一个来自 4 级，其余来自 3 级。在这种情况下，它还需要 10 倍以上的空间（3,720,676,532 字节到 3,531,157,508）。它最终将这些压缩到第 3 级，但我的印象是表格只会在级别上上升。为什么 4 级表被压缩到 3 级？现在我已经在日志中注意到了这一点，我发现它经常发生。例如，这是大约同一时间的另一个：

我不知道这是否有问题。

在 Cassandra 2.2.3 上执行 SELECT 时，我正在处理一个令人费解的行为。我在环中有 4 个节点，我创建了以下键空间、表和索引。

然后我在表上插入一些行。其中一些有空集。我通过默认的 CQL 客户端执行此查询并获得我期望的行：

然后我运行了一些我无法控制的测试。我不知道他们做了什么，但我希望他们阅读并可能插入/更新/删除一些行。我确信他们不会删除或更改索引、表或键空间中的任何设置。

测试后，我通过默认的 CQL 客户端再次登录并运行以下查询。

第一个不返回任何东西。第二个返回所有行，包括 code = 'test' 的行。第三个返回第一个查询无法检索的预期行。

我可以看到这一行与其他行之间的唯一区别是它是包含一些空集的行之一，如前所述。如果我查询另一行也包含一些空集，我会得到相同的行为。

我会说这个问题与二级索引有关。不知何故，在测试期间执行的操作使索引处于看不到某些行的状态。

我显然错过了一些东西。您对可能导致这种行为的原因有任何想法吗？

提前致谢。

更新：

我解决了这个问题，但现在我在其他地方发现了同样的问题。由于问题首次发生，我发现了有关错误之前执行的操作的更多信息：更新为所述列设置 TTL 的特定列。经过一番调查，我发现了一些可能与此问题有关的 Jira 问题：

https://issues.apache.org/jira/browse/CASSANDRA-6782 https://issues.apache.org/jira/browse/CASSANDRA-8206

但是，这些问题似乎已经在 2.0 和 2.1 上得到解决，而我正在使用 2.2。我认为这些更改包含在 2.2 中，但我可能弄错了。

我正在恢复到由 3 个节点组成的全新 Cassandra2.2.5集群。

新集群的初始集群运行状况：

作为Datastax docs 中恢复说明的一部分，我在新集群上执行以下操作：

1）cassandra stop在所有三个节点上一个接一个。

2)cassandra.yaml使用备份的令牌环信息编辑所有三个节点。[来自文档的第 2 步]

3) 从/var/lib/cassandra/data/system/*[Step 4 from docs]中删除内容

4)分别cassandra start在节点10.40.1.1,10.40.1.2上10.40.1.3。

结果： 10.40.1.1重新启动成功：

但是第二个和第三个节点无法重新启动说明：

最终集群运行状况：

我了解删除系统目录后节点的 HostID 可能会更改。

我的问题是：

我是否需要在开始时明确声明以替换自身？文档不完整还是我的步骤中遗漏了什么？

我们计划将目前在 2.0.9 上运行的集群升级到 2.2.6。根据文档和一些博客，人们就地升级 cassandra，即从环中删除一个节点，升级它并再次添加它。我们对遵循这种方法持怀疑态度，因为事情可能会出错（这是一个具有大量 QPS 的高事务数据库）。

因此，我们计划在集群中添加一个新的数据中心，该数据中心将升级 cassandra 版本（2.2）。所以设置应该有两个数据中心，一个是旧的（2.0.9），另一个是新的（2.2.6）

这个数据中心只是一个备份。当数据中心变得稳定时，我们将更改与该数据中心的客户端连接，如果它运行良好，那么我们将使用该数据中心并关闭旧数据中心，否则我们可以回退到旧数据中心并调试出了什么问题。

这个过程是否足够可行，还是我们应该进行就地升级？

数据中心是否可以存在两个 cassandra 版本（2.0 和 2.2）。

这种方法有没有失败？

我有一个由 Java 客户端应用程序使用的 4 个节点的 Cassandra (2.2.1) 集群。复制因子为 3，读写一致性级别为 LOCAL_QUORUM。每个节点都有大约 5 GB 的数据。请求量约为每秒 2-4k。几乎没有删除操作，因此创建了少量的墓碑。

前段时间我注意到读写性能很差，而且随着时间的推移变得更糟——集群变得非常慢。读取（大多数情况下）和写入超时变得非常频繁。硬件应该不是问题，部署集群的服务器在磁盘性能，CPU和RAM资源方面确实很好。

我不清楚问题的原因，但我注意到几个可能指向根本原因的日志条目：

1. Java 客户端应用程序日志中的异常堆栈跟踪：

   com.datastax.driver.core.exceptions.ReadTimeoutException：Cassandra 在读取查询期间以一致性 LOCAL_QUORUM 超时（需要 2 个响应，但只有 1 个副本响应）

有趣的是 1 个节点仍然响应。

2. 失败提示错误的几个条目：

   无法重播 /1.1.1.1 的提示；正在中止（已交付 135922），错误：操作超时 - 仅收到 0 个响应。

3. cassandra 日志中有以下几个异常：

   请求期间出现意外异常；channel = [id: 0x10fc77df, /2.2.2.2:54459 :> /1.1.1.1:9042] java.io.IOException: Error while read(...): Connection timed out at io.netty.channel.epoll.Native .readAddress(Native Method) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.doReadBytes(EpollSocketChannel.java:675) ~[netty -all-4.0.23.Final.jar:4.0.23.Final] 在 io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.epollInReady(EpollSocketChannel.java:714) ~[netty-all-4.0.23.Final. jar:4.0.23.Final] 在 io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:326) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 在 io。 netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:264) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] 在 io.netty.util.concurrent。

4. 失败的批处理错误：

   [<...>] 的准备语句批次大小为 3453794，超过指定阈值 1024000 到 2429794。（请参阅 batch_size_fail_threshold_in_kb）

看起来批处理太大了，顺便说一下我们有很多批处理操作。也许批次会影响系统？

5. 最后，最常见的异常 - 在将日志记录级别切换为 DEBUG 后，这些条目一个接一个出现：

   TIOStreamTransport.java:112 - 关闭输出流时出错。java.net.SocketException: 套接字在 java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:116) 处关闭 ~[na:1.8.0_66] 在 java.net.SocketOutputStream.write(SocketOutputStream.java:153) 处~[na: 1.8.0_66] 在 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) ~[na:1.8.0_66] 在 java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) ~[na:1.8.0_66]在 java.io.FilterOutputStream.close(FilterOutputStream.java:158) ~[na:1.8.0_66] 在 org.apache.thrift.transport.TIOStreamTransport.close(TIOStreamTransport.java:110) ~[libthrift-0.9.2. jar:0.9.2] 在 org.apache.cassandra.thrift.TCustomSocket.close(TCustomSocket.java:197) [apache-cassandra-2.2.1.jar:2.2.1] 在 org.apache.thrift.transport.TFramedTransport .close(TFramedTransport.java:

您对可能导致此问题的原因有任何想法吗？

谢谢！

如果现有 Cassandra 2.2.x 集群中的 vNode 数量发生变化 - 是否会导致该集群中的所有数据丢失？
是否可以更改 vNode 的数量并保留存储在 Cassandra 集群中的所有数据？

添加新的 cassandra 节点后，我遇到了一个奇怪的 cassandra 连接问题。

添加节点前的情况：

• 数据中心 1 的服务器 1 上的 1 个 cassandra 节点
• 完全可操作的 Java 应用程序分布在多台机器上
• 数据中心 1 中的服务器 1 上的 PHP nginx Web 服务器
• 完全可操作的 PHP 应用程序（用于显示结果）

然后我在数据中心 2 中添加了第二台存储服务器。两台存储服务器的复制因子为 1（所有数据都在两台服务器上）。因此我改变了键空间。因此，数据已顺利同步，并已通过 Datastax Devcenter 应用程序检查其有效性。

添加节点后的情况：

• 数据中心 1 的服务器 1 上的 1 个 cassandra 节点
• 数据中心 2 中的服务器 2 上的 1 个 cassandra 节点
• 完全可操作的 Java 应用程序分布在多台机器上
• 数据中心 1 中的服务器 1 上的 PHP nginx Web 服务器
• PHP 应用程序崩溃异常：All connections on all I/O threads are busy..即使有所有可用的连接。

我接下来尝试了什么：

• 我下载了 Github Datastax PHP 代码示例
• 如果我通过控制台 php 命令从代码中运行这段代码，它就可以工作
• 如果我通过 nginx 在浏览器中运行相同的代码，我会再次收到All connections on all I/O threads are busy

我没有更改 nginx 配置或 PHP webapp 中的任何内容。我只是更改了键空间和同步服务器。

知道如何摆脱“连接忙”错误吗？