我在开发系统上使用cassandra节点（一个节点），并且在运行"强测试"（如非常快的写入测试）时，我会遇到很多错误。这些我们在各处都看到了有关它们的问题，而对它们没有真正的答案，只是您不能走得太快。好吧，我通常很好。
但是，今天我像生产中一样使用系统，并获得一张可以产生超时错误的表。这是在读取模式的（错误中的部分写入在套接字上，而不是数据库）。
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
ralf将我指向理查德有答案的页面：
«您只需删除损坏的sstable，然后运行维修即可从复制品中恢复数据。»
所以我今天尝试了，因为我再次遇到了同样的错误，并且实际上奏效了。也就是说，由于我有一个节点，因此根据我的说法，维修实际上是没有用的。但是，"删除损坏的sstable"部分效果很好。一旦我为给定的表进行了磨砂膏，我就可以阅读正在产生超时的行（即，暂停是因为卡桑德拉（Cassandra侧面。）
就我而言，我运行了以下命令，并解决了名为files的表：
nodetool scrub snap_websites files
^ ^
| |
| +--- your table name
+--- your context name