Cassandra - 压实卡住

Question

前期警告 - cassandra 初学者

我已经使用 datastax 企业 ami 在 aws 上设置了一个 4 节点 m3.xlarge 集群，并使用 Cassandra bulkloader 方法加载了数据。

Cassandra 版本为“ReleaseVersion: 2.1.9.791”

四个节点中的一个 - 我开始 buklkload 的那个 - 似乎陷入了压缩状态（过去 12 小时内没有任何变化）

$ nodetool compactionstats
pending tasks: 1
   compaction type   keyspace          table     completed         total    unit   progress
        Compaction   xxx   yyy   60381305196   66396499686   bytes     90.94%
Active compaction remaining time :   0h05m58s

我还注意到，有时该节点变得不可用（在 opscenter 中变红），但过了一段时间（很长一段时间）它又变得可用了。

在 cassandra 日志中是一个例外（见下文）。奇怪的是，还剩下很多磁盘空间。

> ERROR [MemtableFlushWriter:3] 2015-10-29 23:54:21,511 
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:3,5,main]
> org.apache.cassandra.io.FSWriteError: java.io.IOException: No space
> left on device
>         at org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:663)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.java:500)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.io.sstable.SSTableWriter.finish(SSTableWriter.java:453)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:445)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:440)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:389)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:335)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
> ~[guava-16.0.1.jar:na]
>         at org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1154)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
>         at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80] Caused by: java.io.IOException: No space left on device
>         at java.io.FileOutputStream.writeBytes(Native Method) ~[na:1.7.0_80]
>         at java.io.FileOutputStream.write(FileOutputStream.java:345) ~[na:1.7.0_80]
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[na:1.7.0_80]
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[na:1.7.0_80]
>         at org.apache.cassandra.io.util.DataOutputStreamPlus.flush(DataOutputStreamPlus.java:55)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         at org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.close(SSTableWriter.java:657)
> ~[cassandra-all-2.1.9.791.jar:2.1.9.791]
>         ... 12 common frames omitted

Tpstats 输出为

   $ nodetool tpstats
Pool Name                    Active   Pending      Completed   Blocked  All time blocked
CounterMutationStage              0         0              0         0                 0
ReadStage                         0         0          19485         0                 0
RequestResponseStage              0         0         116191         0                 0
MutationStage                     0         0         386132         0                 0
ReadRepairStage                   0         0            848         0                 0
GossipStage                       0         0          46669         0                 0
CacheCleanupExecutor              0         0              0         0                 0
AntiEntropyStage                  0         0              0         0                 0
MigrationStage                    0         0              1         0                 0
Sampler                           0         0              0         0                 0
ValidationExecutor                0         0              0         0                 0
CommitLogArchiver                 0         0              0         0                 0
MiscStage                         0         0              0         0                 0
MemtableFlushWriter               0         0             80         0                 0
MemtableReclaimMemory             0         0             79         0                 0
PendingRangeCalculator            0         0              4         0                 0
MemtablePostFlush                 1        33            127         0                 0
CompactionExecutor                1         1          27492         0                 0
InternalResponseStage             0         0              4         0                 0
HintedHandoff                     0         0              3         0                 0

Message type           Dropped
RANGE_SLICE                  0
READ_REPAIR                  0
PAGED_RANGE                  0
BINARY                       0
READ                         0
MUTATION                     0
_TRACE                       0
REQUEST_RESPONSE             0
COUNTER_MUTATION             0

谁有任何关于如何消除悬挂压实以及为什么会发生这种情况的提示？

非常感谢所有提示！

发送

彼得

Answer 1

假设您正在使用 SizeTieredCompaction 并且您有四个大小为 X 的 SSTable，压缩会将它们合并为一个大小为 Y 的 SSTable > 这个过程会不断重复。

问题： 压缩将创建一个 新的 大小为 Y 的 SSTable 和 both 新旧 SSTable X 的大小在压缩过程中存在。

在最坏的情况下（没有删除和覆盖），压缩将需要 SSTables 使用的磁盘空间的 2 倍，或者更具体地说：在某些时候，您需要有足够的磁盘空间来保存 SSTables尺寸 X 和 Y。

因此，即使您似乎还有足够的空间，但在压缩期间您可能会用完磁盘空间。

您可能想尝试 LeveledCompactionStrategy，因为它需要的压缩空间要少得多（10 x sstable_size_in_mb）。另请参阅 http://www.datastax.com/dev/blog/when-to-use-leveled-compaction 了解何时使用 LeveledCompactionStrategy。

无论您使用哪种压缩策略，都应始终留出足够的可用磁盘空间来容纳流式传输、修复和快照。