在生产最佳实践中更改 Cassandra 压缩，是否首选 nodetool upgradesstables？

Question

我们有一个 cassandra 键空间，其中有 2 个生产表。我们已将其压缩策略从LZ4Compressor（默认）更改为DeflateCompressor

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

因为我们的 cassandra 5 节点集群的每个节点中都有大约 300 GB 的数据，复制因子为 2。是 nodetool upgradesstables 推荐或不作为最佳做法。

来自我们阅读过的所有来源

如有需要

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

来源：

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

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

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

示例 `

错误 [ReadRepairStage:74899] 2018-04-08 14:50:09,779 CassandraDaemon.java:229 - 线程异常 线程[ReadRepairStage:74899,5,main] org.apache.cassandra.exceptions.ReadTimeoutException：操作计时 out - 仅收到 0 个回复。在 org.apache.cassandra.service.DataResolver$RepairMergeListener.close(DataResolver.java:171) ~[apache-cassandra-3.10.jar:3.10] 在 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] 在 org.apache.cassandra.service.AsyncRepairCallback$1.runMayThrow(AsyncRepairCallback.java:50) ~[apache-cassandra-3.10.jar:3.10] 在 org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) ~[apache-cassandra-3.10.jar:3.10] 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_144] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_144] 在 org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) ~[apache-cassandra-3.10.jar:3.10] 在 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：键不匹配 装饰键(1013727261649388230, 715cb15cc5624c5a930ddfce290a690b) （d728e9a275616b0e05a0cd1b03bd9ef6 与 d41d8cd98f00b204e9800998ecf8427e） 在 org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92) ~[apache-cassandra-3.10.jar:3.10] 在 org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233) ~[apache-cassandra-3.10.jar:3.10] 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_144] 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_144] 在 org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) [apache-cassandra-3.10.jar:3.10] 在 java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144] 调试 [GossipStage:1] 2018-04-08 14:50:08,490 FailureDetector.java:457 - 忽略 /10.196.22.208 DEBUG 的间隔时间 2000213620 [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,main] org.apache.cassandra.exceptions.ReadTimeoutException：操作计时 out - 仅收到 0 个回复。在 org.apache.cassandra.service.DataResolver$RepairMergeListener.close(DataResolver.java:171) ~[apache-cassandra-3.10.jar:3.10] 在 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]`

Answer 1

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

这真的取决于你的需求 - 如果不是很紧急，你可以简单地等到正常压缩发生，然后重新压缩数据。