在生产中改变Cassandra压缩最佳实践，nodetool升级表是首选吗？

Question

我们有一个cassandra keyspace，它有两个正在生产的表。我们已将其压缩策略从＜code＞LZ4Compressor＜/code＞（默认）更改为＜code＞DeflateCompressor＞/code

使用< code >更改表“Keyspace”。" TableName " WITH compression = { ' class ':' reduce compressor ' }；

因为我的cassandra 5节点集群的每个节点中都有大约300 GB的数据，复制因子为2。nodetool升级稳定是否推荐或不作为最佳实践。

从我们读过的所有资料来看

如果有必要的话

我可以使用nodetool upgradesstables命令。但我想知道，就我们生产中的数据而言，最佳实践是什么？

来源:

向现有列族添加压缩时，磁盘上的现有表不会立即被压缩。在正常的Cassandra压缩过程中，任何新创建的表都将被压缩，任何现有的表都将被压缩。如有必要，您可以使用node tool upgrades tables(Cassandra 1 . 0 . 4或更高版本)或nodetool scrub强制重写和压缩现有的SSTables

在所有节点完成< code > upgrades tables 后，我的cassandra日志中出现了大量异常

更新 - 运行升级表后，现在我的集群抛出了很多错误

示例 '

错误 [读取重新修久阶段：74899] 2018-04-08 14：50：09，779 卡桑德拉守护进程.java：229 - 线程中的异常[读取修改阶段：74899，5，main] 组织.apache.cassandra.exceptions.ReadTimeout异常：操作超时 - 仅收到 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.Unfired分区iterators$2.close（未过滤分区迭代器.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] 在 org.apache.cassandra.service.DataResolver.compareResponses（DataResolver.java：89） ~[apache-cassandra-3.10.jar：3.10] at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow（异步对对Callback.java：50） ~[apache-cassandra-3.10.jar：3.10] 在组织.apache.cassandra.utils.wrappedrunable.run（包装可运行.java：28） ~[apache-cassandra-3.10.jar：3.10] 在 java.util.concurrent.并发.ThreadPoolExcutor.runWorker（线程池攻击者.java：1149） ~[na：1.8.0_144] 在 java.util.util.并发.线程池检测器运行（线程池检测器.java：1149） ~[na：1.8.0_144] 在 java.pool.并发.线程挖掘者.run（线程池检测器.java：624） ~[na：1.8.0_144] 在组织.apache.cassandra.concurrent.namedThreadFactory.lambda$线程本地定位器$0（命名ThreadFactory.java：79） ~[apache-cassandra-3.10.jar：3.10] 在 java.lang.Thread.run（线程.java：748） ~[na：1.8.0_144] EBUG [读取重新调整阶段：74889] 2018-04-08 14：50：07，777 ReadCallback.java：242 - 摘要不匹配： org.apache.cassandra.service.摘要不匹配：关键修饰键不匹配（1013727261649388230，715cb15cc5624c5a930ddfce290a690b） （d728e9a275616b0e05a0cd1b03bd9ef6 vs d41d8cd98f00b204e9800998ecf8427e） at org.apache.cassandra.service.DigestResolver.compareResponses（DigestResolver.java：92） ~[apache-cassandra-3 .10.jar：3.10] 在组织.apache.cassandra.service.ReadCallback$异步重新修整修运行（读取回溯.java：233） ~[apache-cassandra-3.10.jar：3.10] 在 java.util.concurrent.线程池检测器.runworker（线程池专家.java：1149） [na：1.8.0_144] 在java.util.concurrent.ThreadPoolExecutor$Worker.run（线程池专家.java：624） [na：1.8.0_144] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDealdelocator$0（NamedThreadFactory.java：79） [apache-cassandra-3.10.jar：3.10] at java.lang.Thread.run（Thread.java：：79） 748） ~[na：1.8.0_144] DEBUG [八卦阶段：1] 2018-04-08 14：50：08，490 FailureDetor.java：457 - 忽略 /10.196.22.208 调试的2000213620间隔时间 [读取重新调整阶段：74899] 2018-04-0814：50：09，778 DataResolver.java：169 - 在收到所有 1 个数据和摘要响应后读取修复时超时 错误 [ReadRepairStage：74899] 2018-04-08 14：50：09，779 CassandraDaemon.java：229 - 线程中的异常[读取修复阶段：74899，5，main] org.apache.cassandra.exceptions.读取超时异常异常： 操作超时 - 仅收到 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.Unfired分区iterators$2.close（未过滤分区迭代器.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] 在 org.apache.cassandra.service.DataResolver.compareResponses（DataResolver.java：89） ~[阿帕奇-卡桑德拉-3.10.jar：3.10]'

Answer 1

当您使用< code > node tool upgradestables 时，它会使用您指定的新选项从现有的表中写入新的表。这是一个IO密集型过程，可能会影响集群的性能，因此您需要相应地进行规划。您还需要有足够的磁盘空间来执行此操作。该命令也应该以运行Cassandra的同一用户身份运行。

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