我在开发系统上使用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
答案 0 :(得分：0)
拉尔夫向我指了一个理查德得到答案的页面：
«您可以删除损坏的SSTable然后运行修复以从副本中恢复数据。 »
所以我今天尝试了，因为我再次遇到了同样的错误并且实际上有效。也就是说，由于我有一个节点，修复实际上是无用的。但是，“删除损坏的SSTable”部分很有效。一旦我为给定的表执行了清理，我就可以读取生成超时的行（即因为Cassandra抛出而发生超时，因此永远不会回复thrift，这会在一段时间后决定在客户端上抛出超时错误侧。）
就我而言，我运行了以下命令并解决了名为files的表的问题：
nodetool scrub snap_websites files
^ ^
| |
| +--- your table name
+--- your context name