Question

前期警告 - cassandra初学者

我使用数据存储企业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

任何有关如何进行悬挂压实的提示都会消失，以及为什么这样做会让人感到高兴？

非常感谢所有提示！

的Tx

彼得

Answer 1

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

问题：压缩会创建一个新 SSTable，其大小为 Y ，新旧SSTables在压实过程中存在大小 X

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

因此，即使您有足够的空间，但在压缩过程中可能会耗尽磁盘空间。

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

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

Cassandra - 压实卡住了

1 个答案: