apache::thrift::transport::TTransportException -- Cassandra 超时似乎是因为垃圾？答案

【问题标题】：apache::thrift::transport::TTransportException -- Cassandra times out seemingly because of garbage?apache::thrift::transport::TTransportException -- Cassandra 超时似乎是因为垃圾？
【发布时间】：2014-02-28 07:07:09
【问题描述】：

我在开发系统上使用 Cassandra 节点（一个节点），不久前在运行“强测试”（如在非常快的写入测试中）时，我遇到了很多错误。这些我们到处都能看到关于它们的问题，但没有关于它们的真正答案，只是你不能走得太快。好的，我一般没问题。

但是，今天我像在生产中一样使用该系统，并获得了一个会生成超时错误的表。这是READ模式（错误中的部分写入在套接字上，而不是在数据库中）。

Thrift: Tue Feb  4 01:46:44 2014 TSocket::write_partial() send() <Host: 127.0.0.1 Port: 9160>Broken pipe
terminate called after throwing an instance of 'apache::thrift::transport::TTransportException'
  what():  write() send(): Broken pipe

在这种情况下，最大的问题是我无法访问其中一个表中的一行。尝试访问该行总是会超时。我重新启动了节点，等了一段时间，没有任何变化。该行刚刚被冲洗。

以前有人遇到过这样的问题吗？如果是这样，你有办法解决它吗？我可以重新生成该特定行，但是在具有许多节点的集群中会发生什么？一个节点上的一行能否决定破坏整个系统？（那一行打破了我的开发系统！）如果你有想法，我想听听他们的意见，所以下次发生这种情况时，我可以研究修复而不是炸毁整个数据库并创建一个新的（我可以只需删除表并重新启动，无需删除整个集群，但仍然......但这不是生产系统中的解决方案。）

======== 更新

啊！没关系，我正在查看错误的日志文件（开发系统，我会告诉你......）。错误是 EOFException。

ERROR [ReadStage:29174] 2014-02-04 01:17:00,587 CassandraDaemon.java (line 185) Exception in thread Thread[ReadStage:29174,5,main]
java.io.IOError: java.io.EOFException
at org.apache.cassandra.db.Column$1.computeNext(Column.java:79)
at org.apache.cassandra.db.Column$1.computeNext(Column.java:64)
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:88)
at org.apache.cassandra.db.columniterator.SimpleSliceReader.computeNext(SimpleSliceReader.java:37)
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at org.apache.cassandra.db.columniterator.SSTableSliceIterator.hasNext(SSTableSliceIterator.java:82)
at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:157)
at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:140)
at org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:200)
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:189)
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:294)
at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1468)
at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1294)
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:332)
at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:65)
at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1365)
at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1897)
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:724)
Caused by: java.io.EOFException
at java.io.RandomAccessFile.readFully(RandomAccessFile.java:416)
at java.io.RandomAccessFile.readFully(RandomAccessFile.java:394)
at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:348)
at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:392)
at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:355)
at org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:118)
at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:85)
at org.apache.cassandra.db.Column$1.computeNext(Column.java:75)
... 28 more

【问题讨论】：

Cassandra 是否也会记录错误？还是只是客户？超时通常会在日志中显示。
不，我在日志中看不到任何内容。我想错误会出现在那里......我会确保提高日志级别以防它再次发生，以便下次获得更多信息。
我猜我评论太快了！查看日志设置，它在 INFO 上，所以我已经得到了相当多的日志。事实是我在看一个旧日志。我现在可以看到问题中更新的错误。
这thread 有帮助吗？
啊！这是一个好消息，通过删除 sstable 可以解决自动复制问题。也就是说，这意味着我们最好有 3 个以上的节点来确保。一个节点环境可能会被排除在生产系统之外......话虽如此，我下次遇到这样的错误时必须进行测试以确保它有效！

标签： timeout cassandra

【解决方案1】：

Ralf 将我指向一个页面，Richard 回答说：

« 您可以删除损坏的 SSTable，然后运行修复以从副本中恢复数据。 »

所以我今天尝试了，因为我再次遇到了同样的错误并且它确实有效。也就是说，由于我只有一个节点，因此据我所知，修复实际上是无用的。但是，“删除损坏的 SSTable”部分效果很好。一旦我对给定的表进行了擦洗，我就可以读取产生超时的行（即超时发生是因为 Cassandra 抛出，因此从不回复 thrift，过了一会儿决定在客户端抛出超时错误边。）

就我而言，我运行了以下命令并为名为@987654321@ 的表解决了问题：

nodetool scrub snap_websites files
               ^             ^
               |             |
               |             +--- your table name
               +--- your context name

【讨论】：