【发布时间】：2019-11-25 03:52:51
【问题描述】：
我计划将 cassandra 版本从 2.2 升级到 3.11。同时我想将现有的表压缩策略从 SizeTieredCompactionStrategy 更改为 TimeWindow。我想自动化这两个任务。如何在有效地将 cassandra 版本从 2.2x 升级到 3.11x 的同时更改压缩策略？
我正在运行 3 节点 apache cassandra 集群作为 docker 容器，它保存 45 天 TTL 的时间序列数据。
考虑-
- 更改表的压缩策略将触发所有重写 SSTable 的节点的压缩。
- 由于 cassandra 3.0 中的存储引擎更改，使用“upgradesstables”命令进行重大升级将导致重写 SSTables
有没有办法通过避免一次又一次地重写SSTable来优化这个过程。
这就是我的想法-
- 禁用压缩
- 更改表以更改压缩
- 将 Cassandra 升级到 3.x
- 启用压缩
我希望 upgradesstables 会尊重新的压缩并避免一次 SSTable 写入。
这是一个正确的方法吗？
【问题讨论】：
-
我同意你关于文档所述的两点。然而，第 1 点，虽然是，我将使用这个词，建议，在他的文档中，并不是实际发生的。当您将压缩策略更改为（在您的情况下为 TWCS）时，不会立即重写所有现有的 sstables。将使用 TWCS 格式创建新的 sstables，当您达到指定的限制（X 个存储桶）时，旧的 sstables 将被丢弃或被清理。
-
尽管有可能，但不建议同时进行两个或多个更改：如果出现故障，故障排除将更加困难。如果除了同时进行之外别无选择，最好先彻底测试它，我们通常会从恢复的备份中创建一个单独的集群，并在对“实时”服务器执行操作之前对其应用更改。
标签： cassandra upgrade datastax