我们有一个cassandra键空间,其中有2个表正在制作中。我们已将其压缩策略从LZ4Compressor
(默认值)更改为DeflateCompressor
ALTER TABLE "Keyspace"."TableName" WITH compression = {'class': 'DeflateCompressor'};
因为我的cassandra 5节点集群的每个节点都有大约300 GB的数据,复制因子为2
nodetool upgradesstables
建议或不作为最佳做法。
从我们阅读的所有来源
如有必要
我可以使用nodetool upgradesstables命令。但我想知道实际上最佳实践作为我们生产的数据?
来源:
将压缩添加到现有列族时,磁盘上的现有SSTable不会 立即压缩。创建的任何新SSTable都将被压缩,任何现有的SSTable都将被压缩 在正常的Cassandra压实过程中压缩。如有必要,您可以强制使用现有的SSTable 使用nodetool upgradedesstables(Cassandra 1.0.4或更高版本)或nodetool scrub重写和压缩
所有节点完成后upgradesstables
我的cassandra日志中遇到大量异常
更新 - 运行upgradesstables
后,我的群集会抛出很多错误
样品 `
错误[ReadRepairStage:74899] 2018-04-08 14:50:09,779 CassandraDaemon.java:229 - 线程中的异常 主题[ReadRepairStage:74899,5,主] org.apache.cassandra.exceptions.ReadTimeoutException:操作定时 out - 只收到0回复。在 org.apache.cassandra.service.DataResolver $ RepairMergeListener.close(DataResolver.java:171) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.db.partitions.UnfilteredPartitionIterators $ 2.close(UnfilteredPartitionIterators.java:182) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:82) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.service.DataResolver.compareResponses(DataResolver.java:89) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.service.AsyncRepairCallback $ 1.runMayThrow(AsyncRepairCallback.java:50) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 〜[apache-cassandra-3.10.jar:3.10] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 〜[na:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor中的$ Worker.run(ThreadPoolExecutor.java:624) 〜[na:1.8.0_144] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda $ threadLocalDeallocator $ 0(NamedThreadFactory.java:79) 〜[apache-cassandra-3.10.jar:3.10] at java.lang.Thread.run(Thread.java:748)〜[na:1.8.0_144] EBUG [ReadRepairStage:74889] 2018-04-08 14:50:07,777 ReadCallback.java:242 - 摘要不匹配:org.apache.cassandra.service.DigestMismatchException:键不匹配 DecorativeKey(1013727261649388230,715cb15cc5624c5a930ddfce290a690b) (d728e9a275616b0e05a0cd1b03bd9ef6 vs d41d8cd98f00b204e9800998ecf8427e) 在 org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.service.ReadCallback $ AsyncRepairRunner.run(ReadCallback.java:233) 〜[apache-cassandra-3.10.jar:3.10] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_144] at java.util.concurrent.ThreadPoolExecutor中的$ Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_144] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda $ threadLocalDeallocator $ 0(NamedThreadFactory.java:79) [apache-cassandra-3.10.jar:3.10] at java.lang.Thread.run(Thread.java:748)〜[na:1.8.0_144] DEBUG [GossipStage:1] 2018-04-08 14:50:08,490 FailureDetector.java:457 - 忽略2000213620的间隔时间为/10.196.22.208 DEBUG [ReadRepairStage:74899] 2018-04-08 14:50:09,778 DataResolver.java:169 - 在收到所有1个数据和摘要响应后进行读取修复时超时错误[ReadRepairStage:74899] 2018-04-08 14:50:09,779 CassandraDaemon.java:229 - 线程中的异常 主题[ReadRepairStage:74899,5,主] org.apache.cassandra.exceptions.ReadTimeoutException:操作定时 out - 只收到0回复。在 org.apache.cassandra.service.DataResolver $ RepairMergeListener.close(DataResolver.java:171) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.db.partitions.UnfilteredPartitionIterators $ 2.close(UnfilteredPartitionIterators.java:182) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:82) 〜[apache-cassandra-3.10.jar:3.10] at org.apache.cassandra.service.DataResolver.compareResponses(DataResolver.java:89) 〜[Apache的卡桑德拉-3.10.jar:3.10]`
答案 0 :(得分:1)
当您使用nodetool upgradesstables
时,它会从现有的SSTable中编写新的SSTable,但使用您指定的新选项。这是IO密集型过程,可能会影响群集的性能,因此您需要相应地进行规划。您还需要有足够的磁盘空间来执行此操作。此命令也应该与运行Cassandra的用户一样运行。
这实际上取决于您的需求 - 如果不紧急,您可以等到正常压缩发生,然后数据将被重新压缩。