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

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

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

1 个答案: