在生产最佳实践中改变Cassandra压缩是nodetool upgradedesstables首选吗?

时间:2018-02-19 10:18:50

标签: cassandra cassandra-2.0 production cassandra-3.0 cassandra-2.1

我们有一个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]`

1 个答案:

答案 0 :(得分:1)

当您使用nodetool upgradesstables时,它会从现有的SSTable中编写新的SSTable,但使用您指定的新选项。这是IO密集型过程,可能会影响群集的性能,因此您需要相应地进行规划。您还需要有足够的磁盘空间来执行此操作。此命令也应该与运行Cassandra的用户一样运行。

这实际上取决于您的需求 - 如果不紧急,您可以等到正常压缩发生,然后数据将被重新压缩。