在生产最佳实践中改变Cassandra压缩,是否首选nodetool升级表?

我们有一个cassandra密钥空间,其中有2个表正在生产中。我们已将其压缩策略从 LZ4Compressor (默认设置)为 DeflateCompressor

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

因为我们在我的cassandra 5节点集群的每个节点上都有大约300 GB的数据,复制系数为2。是 nodetool upgradesstables 是否推荐为最佳实践。

从我们读到的所有来源

如有必要

我可以使用nodetool upgradessstables命令。但我想知道 最佳实践是什么 作为我们的数据,它正在生产中?

资料来源:

向现有列族添加压缩时,磁盘上的现有SSTables不会 立即压缩。将压缩创建的任何新SSTables,并将压缩所有现有SSTables 在正常Cassandra压实过程中压缩。如有必要,可以强制现有SSTables 使用nodetool upgradesstables(Cassandra 1.0.4或更高版本)或nodetool scrub重写和压缩

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

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

样品 `

错误[ReadRepairStage:74899]2018-04-08 14:50:09779 卡桑德拉迪蒙。java:229-线程中出现异常 线程[ReadRepairStage:74899,5,main] 组织。阿帕奇。卡桑德拉。例外情况。ReadTimeoutException:操作已计时 out-仅收到0个响应。在 组织。阿帕奇。卡桑德拉。服务DataResolver$RepairMergeListener。关闭(DataResolver.java:171) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。数据库。分区。未过滤分区计算器2美元。关闭(UnfilteredPartitionIterators.java:182) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。数据库。使改变BaseIterator。关闭(BaseIterator.java:82) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。服务数据解析程序。比较响应(DataResolver.java:89) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。服务AsyncRepairCallback$1。RunMaytrow(AsyncRepairCallback.java:50) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。UTIL。包装纸。run(WrappedRunnable.java:28) ~[apache-cassandra-3.10.jar:3.10]at Java语言util。同时发生的线程池执行器。runWorker(ThreadPoolExecutor.java:1149) ~(na:1.8.0\u 144)at Java语言util。同时发生的ThreadPoolExecutor$工作者。运行(ThreadPoolExecutor.java:624) ~(na:1.8.0\u 144)at 组织。阿帕奇。卡桑德拉。同时发生的命名线程工厂。lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) ~[apache-cassandra-3.10.jar:3.10]at Java语言lang.Thread。运行(Thread.java:748)~[na:1.8.0\u 144]EBUG 【ReadRepair阶段:74889】2018-04-08 14:50:07777 ReadCallback。爪哇:242 -摘要不匹配:组织。阿帕奇。卡桑德拉。服务DigestMismatchException:键不匹配 装饰钥匙(1013727261649388230、715CB15CC5624C55A930DDFCE290A690B) (d728e9a275616b0e05a0cd1b03bd9ef6与d41d8cd98f00b204e9800998ecf8427e) 在 组织。阿帕奇。卡桑德拉。服务DigestResolver。比较响应(DigestResolver.java:92) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。服务ReadCallback$AsyncRepairRunner。运行(ReadCallback.java:233) ~[apache-cassandra-3.10.jar:3.10]at Java语言util。同时发生的线程池执行器。runWorker(ThreadPoolExecutor.java:1149) [不适用:1.8.0\u 144]at Java语言util。同时发生的ThreadPoolExecutor$工作者。运行(ThreadPoolExecutor.java:624) [不适用:1.8.0\u 144]at 组织。阿帕奇。卡桑德拉。同时发生的命名线程工厂。lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) [apache-cassandra-3.10.jar:3.10] Java语言lang.Thread。运行(Thread.java:748)~[na:1.8.0\u 144]调试 【GossipStage:1】2018-04-08 14:50:08490故障检测器。爪哇:457- 忽略/10.196.22.208调试的间隔时间2000213620 【ReadRepairStage:74899】2018-04-08 14:50:09778数据解析器。爪哇:169 -接收到所有1个数据和摘要响应后进行读取修复时超时错误[ReadRepairStage:74899]2018-04-08 14:50:09779 卡桑德拉迪蒙。java:229-线程中出现异常 线程[ReadRepairStage:74899,5,main] 组织。阿帕奇。卡桑德拉。例外情况。ReadTimeoutException:操作已计时 out-仅收到0个响应。在 组织。阿帕奇。卡桑德拉。服务DataResolver$RepairMergeListener。关闭(DataResolver.java:171) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。数据库。分区。未过滤分区计算器2美元。关闭(UnfilteredPartitionIterators.java:182) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。数据库。使改变BaseIterator。关闭(BaseIterator.java:82) ~[apache-cassandra-3.10.jar:3.10]at 组织。阿帕奇。卡桑德拉。服务数据解析程序。比较响应(DataResolver.java:89) ~[apache-cassandra-3.10.jar:3.10]`