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

我们有一个cassandra键空间，有2个表正在制作中 . 我们已将其压缩策略从 LZ4Compressor （默认值）更改为 DeflateCompressor

使用 ALTER TABLE "Keyspace"."TableName" WITH compression = {'class': 'DeflateCompressor'};

因为我的cassandra 5节点集群的每个节点中有大约300 GB的数据，复制因子为2.建议使用 nodetool upgradesstables 作为最佳做法 .

从我们阅读的所有资料来源

如有必要

我可以使用nodetool upgradesstables命令 . 但我想知道 what is actually the best practice 作为我们的 生产环境 数据？

资料来源：

将压缩添加到现有列族时，磁盘上的现有SSTable不会立即压缩 . 创建的任何新SSTable都将被压缩，并且在正常的Cassandra压缩过程中将压缩任何现有的SSTable . 如有必要，可以使用nodetool upgradesstables（Cassandra 1.0.4或更高版本）或nodetool scrub强制重写和压缩现有的SSTables

所有节点完成后 upgradesstables 我的cassandra日志中遇到大量异常

更新 - 运行 upgradesstables 后，我的群集丢失了很多错误

样品`

错误[ReadRepairStage：74899] 2018-04-08 14：50：09,779 CassandraDaemon.java:229 - 线程中的异常线程[ReadRepairStage：74899,5，main] org.apache.cassandra.exceptions.ReadTimeoutException：操作超时 - 只收到0回复 . at 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] 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] atg.apache.cassandra.utils.WrappedRunnable.run（WrappedRunnable.java:28）〜[apache-cassandra-3.10.jar：3.10] at java.util.concurrent .treadPoolExecutor.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.lamb在$ java.lang.Thread.run（Thread.java:748）〜[na：1.8.0_144] EBUG [ReadRepairStage：da $ threadLocalDeallocator $ 0（NamedThreadFactory.java:79）〜[apache-cassandra-3.10.jar：3.10] 74889] 2018年4月8日14：50：07777 ReadCallback.java:242 - 汇总不匹配：org.apache.cassandra.service.DigestMismatchException：在org.apache不匹配关键DecoratedKey（1013727261649388230，715cb15cc5624c5a930ddfce290a690b）（d728e9a275616b0e05a0cd1b03bd9ef6 VS d41d8cd98f00b204e9800998ecf8427e） . org.apache.cassandra.service.ReadCallback $ AsyncRepairRunner.run（ReadCallback.java:233）〜[apache]中的cassandra.service.DigestResolver.compareResponses（DigestResolver.java:92）〜[apache-cassandra-3.10.jar：3.10] -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.ja va：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数据和摘要响应ERROR [ReadRepairStage：74899] 2018-04-08 14:50:09,779 CassandraDaemon.java:229 - 线程中的异常Thread [ReadRepairStage：74899,5，main] org.apache.cassandra.exceptions.ReadTimeoutException：操作超时 - 仅收到0个响应 . at 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] org.apache.cassandra.db.transform.BaseIterator.close（BaseIterator.java:82）〜[apache-cassandra-3.10.jar：3.10]在org.apache.cassandra.service.DataResolver.compareResponses（DataResolver.java:89）〜[apache-cassandra-3.10.jar：3.10]